- Scope filtering only applies to classic PATs which return X-OAuth-Scopes
- Fine-grained PATs and other token types skip filtering (all tools shown)
- Updated docs to clarify PAT filtering vs OAuth scope challenges
Scope filtering is now a built-in feature rather than a configurable option.
The server automatically fetches token scopes at startup and filters tools
accordingly. If scope detection fails, it logs a warning and continues with
all tools available.
Add the ability to filter tools based on token scopes for PAT users.
This uses an HTTP HEAD request to GitHub's API to discover token scopes.
New components:
- pkg/scopes/filter.go: HasRequiredScopes checks if scopes satisfy tool requirements
- pkg/scopes/fetcher.go: FetchTokenScopes gets scopes via HTTP HEAD to GitHub API
- pkg/github/scope_filter.go: CreateScopeFilter creates inventory.ToolFilter
Integration:
- Add --filter-by-scope flag to stdio command (disabled by default)
- When enabled, fetches token scopes on startup
- Tools requiring unavailable scopes are hidden from tool list
- Gracefully continues without filtering if scope fetch fails (logs warning)
This allows the OSS server to have similar scope-based tool visibility
as the remote server, and the filter logic can be reused by remote server.
Map iteration in Go is non-deterministic, which causes doc generation
to produce different output on each run. Sort the scope slices in:
- ScopeSet.ToSlice()
- ScopeSet.ToStringSlice()
- ExpandScopes()
public_repo is implicit - the GitHub API handles the distinction between
public and private repos. Using repo as the required scope is more
consistent with our enforcement model:
- PATs: tools visible if token has repo scope
- OAuth: scope challenge requests repo scope
- Add ScopeHierarchy map defining parent-child scope relationships
- Add ExpandScopes() function to derive accepted scopes from required scopes
- Update NewTool/NewToolFromHandler to take []scopes.Scope and auto-derive AcceptedScopes
- Add new scope constants: NoScope, User, ReadUser, UserEmail, ReadPackages, WritePackages
- Update all tool files to use new signature with typed scopes
- Add comprehensive tests for ExpandScopes
The scope hierarchy allows automatic derivation of accepted scopes:
- repo → public_repo, security_events
- admin:org → write:org → read:org
- project → read:project
- write:packages → read:packages
- user → read:user, user:email
This enables the remote server to consume scope info directly from OSS tools.
- Replace NewToolWithScopes with updated NewTool that includes scope parameters
- All tools now use the same constructor with explicit scope requirements
- Documentation only shows accepted scopes when they differ from required
- Removed NewToolWithScopes and NewToolFromHandlerWithScopes helper functions
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
- Updated all remaining tools with OAuth scope information
- Added scope documentation generation to generate-docs command
- Documentation now shows Required and Accepted OAuth scopes for each tool
- All 100+ tools now have scope information defined
- Tests pass, linter passes, documentation generated successfully
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
When multiple tools share the same name but have different feature flags
(like GetJobLogs and ActionsGetJobLogs both named "get_job_logs"),
filterToolsByName was only returning the first match. This caused the
remote server to fail with "unknown tool" error when the first matching
tool was disabled by feature flags, even though another variant was enabled.
The fix modifies filterToolsByName to return ALL tools with matching names,
allowing the feature flag filtering in AvailableTools to select the correct
variant based on the enabled flags.
Fixes#1714
Signed-off-by: majiayu000 <1835304752@qq.com>
Change the parameter name in assign_copilot_to_issue tool from
'issueNumber' (camelCase) to 'issue_number' (snake_case) to match
the naming convention used by all other tools in the issues toolset.
This improves API consistency and makes the tool parameters more
predictable for users and AI models.
Fixes#1239
Signed-off-by: majiayu000 <1835304752@qq.com>
The CodeQL workflow requires security-events write permission and access
to internal GitHub registries/packs that aren't available in forks.
Adding a condition to only run on the main repository prevents workflow
failures in forked repositories.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Replace string conversions with mcp.IconThemeLight and mcp.IconThemeDark
constants to match the SDK's typed IconTheme field. This fixes the CI build
errors where string literals were being used instead of the proper IconTheme type.
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>