CodeQL / Analyze (actions) (push) Has been cancelled
CodeQL / Analyze (javascript) (push) Has been cancelled
Build and Test Go Project / build (macos-latest) (push) Has been cancelled
Build and Test Go Project / build (ubuntu-latest) (push) Has been cancelled
Build and Test Go Project / build (windows-latest) (push) Has been cancelled
Adds a sensible logging integration on top of the (currently unused)
observability.Exporters scaffolding:
* pkg/github/logging_middleware.go
ToolLoggingMiddleware times every tools/call and logs at Debug on
success / Error on failure (Go error or IsError result). It enriches
a *slog.Logger with mcp.method and mcp.tool, then stores it on the
context via observability.ContextWithLogger so tool handlers pick up
the request-scoped logger automatically from deps.Logger(ctx).
* pkg/observability/logger_context.go
ContextWithLogger / LoggerFromContext helpers.
* pkg/observability/log_level.go
ParseLogLevel for 'debug|info|warn|error'.
* --log-level flag / GITHUB_LOG_LEVEL env var
Fills an obvious gap: previously levels were hard-coded (stderr=Info,
file=Debug). The default behaviour is preserved when the flag is empty.
* Fix fmt.Fprintf(os.Stderr, ...) feature-flag check reporting in
BaseDeps.IsFeatureEnabled / RequestDeps.IsFeatureEnabled — these
previously bypassed the structured logger entirely.
Tool handler code is intentionally untouched. The middleware gives every
tool a duration/outcome log line uniformly; tools that want richer
structured logs can opt in via deps.Logger(ctx).
Tests cover the middleware (success / error / IsError / non-tool
pass-through / missing deps), the context helpers, level parsing, and
the BaseDeps.Logger(ctx) context fallback.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Rebase PR #2282 onto main (post-#2332) and unify feature flag
allowlists into a single source of truth.
- Add MCPAppsFeatureFlag, AllowedFeatureFlags, InsidersFeatureFlags,
and ResolveFeatureFlags in feature_flags.go
- AllowedFeatureFlags includes all user-controllable flags (MCP Apps +
granular), InsidersFeatureFlags only includes MCPAppsFeatureFlag
- HeaderAllowedFeatureFlags() now delegates to AllowedFeatureFlags
- Builder uses feature checker instead of insidersMode bool
- Remove InsidersOnly field from ServerTool and WithInsidersMode from
Builder
- HTTP feature checker uses ResolveFeatureFlags for per-request
resolution with insiders expansion
- Tool handlers check MCPAppsFeatureFlag via IsFeatureEnabled instead
of InsidersMode
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The HTTP server now respects the same static CLI flags as the stdio
server: --toolsets, --tools, --exclude-tools, --read-only,
--dynamic-toolsets, and --insiders.
A static inventory is built once at startup from these flags, producing
a pre-filtered tool/resource/prompt universe. Per-request headers
(X-MCP-Toolsets, X-MCP-Tools, etc.) can only narrow within these
bounds, never expand beyond them. When no static flags are set, the
existing behavior is preserved — headers have full access to all
toolsets.
Fixes#2156
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Instead of new CLI flags (--server-name, --server-title), reuse the
existing string override mechanism that already supports tool title/
description overrides throughout the codebase.
Users can now configure the server name and title via:
- GITHUB_MCP_SERVER_NAME / GITHUB_MCP_SERVER_TITLE env vars
- "SERVER_NAME" / "SERVER_TITLE" keys in github-mcp-server-config.json
This is consistent with how all other user-visible strings are
overridden (e.g. GITHUB_MCP_TOOL_GET_ME_USER_TITLE). No new struct
fields or CLI flags are needed.
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
Allows users running multiple GitHub MCP Server instances (e.g., for
github.com and GitHub Enterprise Server) to override the server name and
title in the MCP initialization response.
- Add --server-name / GITHUB_SERVER_NAME flag+env to override name
- Add --server-title / GITHUB_SERVER_TITLE flag+env to override title
- Defaults remain "github-mcp-server" and "GitHub MCP Server"
- Applies to both stdio and HTTP server modes
- Add tests for default and custom name/title
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
CodeQL / Analyze (actions) (push) Has been cancelled
Build and Test Go Project / build (macos-latest) (push) Has been cancelled
Build and Test Go Project / build (ubuntu-latest) (push) Has been cancelled
Build and Test Go Project / build (windows-latest) (push) Has been cancelled
* Move scope storage into its own context key, separately from token info.
This allows us to provide scopes seperately in the remote server, where
we have scopes before we do the auth.
* Skip token extraction if token info already exists in context.
This is to avoid redundant token extraction in remote setup where token info may have already been extracted earlier in the request lifecycle.
* Check for existing scopes in context before fetching from GitHub API in scope challenge middleware
* Return error type for unknown tools in inventory builder and handle it in HTTP handler
Create a shared mcp.SchemaCache in RunHTTPServer and pass it through
to each per-request MCP Server via ServerOptions. This avoids repeated
JSON schema reflection and resolution when a new Server is created for
every request in stateless mode, matching the pattern used by the
remote server.
Matt Holloway