Are tools and toolsets supported when running in http mode?

[dahera]

I have been running GitHub MCP Server in http mode identifying tools and toolsets in 2 different way but server does not limit the client from using tools outside those defined.

1. Using environment variables

docker run --rm -p 8082:8082 -e GITHUB_TOOLS="tool`,tool2" -e GITHUB_TOOLSETS="toolset1,toolset2" ghcr.io/github/github-mcp-server:0.32.0 http

2. Using global flags

docker run --rm -p 8082:8082 ghcr.io/github/github-mcp-server:0.32.0 http --tools "tool`,tool2" --toolsets "toolset1,toolset2"

Expected result: MCP Clients will only be able to use tools listed.

Actual result: MCP Clients are able to use all tools.

[aniruddhaadak80]

This looks like a real boundary issue rather than just a docs misunderstanding. If the server advertises or accepts tools outside the configured allowlist in http mode, then tool scoping is not actually enforceable at the transport boundary, which defeats a big part of the safety story.nnWhat would help maintainers most is a minimal repro showing the exact tool list returned by the server and one request that succeeds outside the declared set. If the behavior differs between stdio and http, that is also worth calling out explicitly because people will assume the flags are transport-independent.

[dahera]

Thanks @aniruddhaadak80 ! I just want to point out that the http --help command shows flags and global flags as viable options. That's why I was expecing --tools and --toolsets to take effect on enabled tools.
See:

docker run -it --rm ghcr.io/github/github-mcp-server:0.32.0 http --help
Start an HTTP server that listens for MCP requests over HTTP.

Usage:
  server http [flags]

Flags:
      --base-path string   Externally visible base path for the HTTP server (for OAuth resource metadata)
      --base-url string    Base URL where this server is publicly accessible (for OAuth resource metadata)
  -h, --help               help for http
      --port int           HTTP server port (default 8082)
      --scope-challenge    Enable OAuth scope challenge responses

Global Flags:
      --content-window-size int          Specify the content window size (default 5000)
      --dynamic-toolsets                 Enable dynamic toolsets
      --enable-command-logging           When enabled, the server will log all command requests and responses to the log file
      --exclude-tools strings            Comma-separated list of tool names to disable regardless of other settings
      --export-translations              Save translations to a JSON file
      --features strings                 Comma-separated list of feature flags to enable
      --gh-host string                   Specify the GitHub hostname (for GitHub Enterprise etc.)
      --insiders                         Enable insiders features
      --lockdown-mode                    Enable lockdown mode
      --log-file string                  Path to log file
      --read-only                        Restrict the server to read-only operations
      --repo-access-cache-ttl duration   Override the repo access cache TTL (e.g. 1m, 0s to disable) (default 5m0s)
      --tools strings                    Comma-separated list of specific tools to enable
      --toolsets strings                 Comma-separated list of tool groups to enable (no spaces).
                                         Available: actions, code_security, copilot, dependabot, discussions, gists, git,
                                                     issues, labels, notifications, orgs, projects, pull_requests, repos,
                                                     secret_protection, security_advisories, stargazers, users
                                         Special toolset keywords:
                                           - all: Enables all available toolsets
                                           - default: Enables the default toolset configuration of:
                                                     context, copilot, issues, pull_requests, repos, users
                                         Examples:
                                           - --toolsets=actions,gists,notifications
                                           - Default + additional: --toolsets=default,actions,gists
                                           - All tools: --toolsets=all

[dahera]

Should --help for http be fixed? Or should the flags take effect even in htttp? I'd vote for the latter.

[dahera]

@SamMorrowDrums , what do you think about this ⬆️

[SamMorrowDrums]

Ran it by the team. I expect limiting available tools to a preset max via static config is something that admins will like to specify, and then individual users could still select toolsets etc. within the bounds of what's actually available, so if static configuration allows three toolsets, end users could use headers to access any combination of those three, but no others...

Seems reasonable, I will hopefully have gathered thoughts from colleagues soon.

[dahera]

Awesome! Thanks @SamMorrowDrums I hope this can be implemented and released soon. If this becomes an enhancment will a ticket be added to this conversation for tracking?

[SamMorrowDrums]

@dahera you need to use the header configuration (mentioned in the remote server documentation). In http mode the server respects configuration per user that connects, not a global configuration for the whole server like STDIO.

Add headers like x-mcp-toolsets or add /x/issues to the route. The behaviour should be consistent with the remote server behaviour.

[dahera]

@SamMorrowDrums the use case I need to support is having a remote http server which allows multiple users connect with their own authorization and utlize tools from a limited predefined set (just like the Atlassian MCP Server)

[SamMorrowDrums]

@dahera your best bet is to use this repo as a library and do that yourself. All the components are there.

Alternatively put some http forwarder/reverse proxy in front and force set all the headers that control available tools.

I am not saying I'm against the possibility of a constrained http option, but at GitHub we use this repo as library for remote server deployment repo and the works really well for us, and I personally think it's a better pattern for self hosting, especially with customisation.

Let me know if you have any success. Can consider constraining remote server at startup also.

[dahera]

Thanks for your response @SamMorrowDrums !

I had actually implemented the http forwarder/reverse proxy idea last week, it worked, but was concerned about performance and maintenance.

I think it would be great if GitHub MCP supported these out of the box, similar to what sooperset Atlassian does - it might not be that hard to pass through those global flags into http mode. I'll dive into GitHub MCP code to look for ways to do this.

Thanks again!