ghe-mcp-gateway

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action (e.g., get vs list, different alert types, branch protection vs permissions). There is no ambiguity between tools; they are clearly differentiated by their target and verb.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (get_*, list_*, set_*, resolve_*) in snake_case. The only outlier is 'graphql_query', which deviates from the pattern but is a generic utility.
Tool Count4/5
21 tools is slightly above the typical well-scoped range (3-15), but given the breadth of GitHub admin functionality covered (branch protection, security alerts, permissions, webhooks), it is still reasonable and not excessive.
Completeness3/5
The tool set covers reading many resources and some write operations (permissions, branch protection, alert resolution). However, it lacks create/delete operations for repos, teams, and webhooks, which are notable gaps for a full admin gateway.
Average 3.5/5 across 21 of 21 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey all behavioral traits. It only indicates the returned data but does not mention authentication requirements, rate limits, or whether the operation is read-only. The agent is left to assume safe behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. However, it lacks structured formatting (e.g., bullet points) that could improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2-param, no output schema), the description provides basic functional context but omits parameter details and return value structure, leaving the agent partially uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning to the two parameters (owner, repo). The agent must rely solely on parameter names, which is insufficient for unambiguous invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and resource (single repository) and specifies the details returned (settings, visibility, permissions). However, it does not explicitly distinguish from sibling tools like get_repo_permission, which may overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_repositories or get_repo_permission. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the basic operation (listing members) and the role filter. It fails to mention pagination, rate limits, ordering, or any side effects. The description is essentially a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences. It is front-loaded with the core purpose. Every word serves a purpose. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and only two parameters, the description is incomplete. It does not explain the behavior when role is omitted (default behavior), nor does it address pagination or sorting. The org parameter is left unexplained. The tool's complexity is low, but the description fails to cover essential usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to the role parameter by listing its possible values ('all | admin | member'), but it does not describe the org parameter at all. The default value for role is not mentioned. Partial compensation earns a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List members of an organization.' The verb 'list' and resource 'members of an organization' are specific. However, it does not distinguish itself from sibling tools like list_repo_collaborators or list_team_members, though those are different resources, so some differentiation is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage hints by listing the role filter options ('all | admin | member'), implying when to use the role parameter. However, it offers no guidance on when to use this tool vs. alternatives, no prerequisites, and no exclusions. The agent receives little help in deciding between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It only states the basic function and role filter, omitting any behavioral aspects like authentication requirements, rate limits, pagination, or whether the output is list or paginated. The presence of an output schema is not reflected in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using only two sentences to convey purpose and a parameter option. There is no unnecessary information, but the structure could be improved by front-loading the purpose more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and the presence of an output schema, the description should cover prerequisites, required parameters, and constraints. It does not mention that org and team_slug are required, nor does it explain any special behaviors. Completeness is low for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It partially does by enumerating valid role values ('all', 'maintainer', 'member'), but does not describe org or team_slug. The description adds some meaning to one of three parameters, which is helpful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'members of a team', which aligns with the tool name. The addition of role options adds specificity. However, it does not explicitly differentiate from siblings like list_organization_members or list_repo_collaborators, but the context makes it distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_organization_members for org-level member listing or list_repo_collaborators for repository collaborators. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or pagination. The phrase 'List all...' implies a read operation, but no explicit disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 10 words, directly stating the action and output. No unnecessary information, efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and an existing output schema, the description is too minimal. It does not explain the parameter or any additional context like scope or pagination, leaving the agent to infer critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the required 'org' parameter at all. Schema description coverage is 0%, and the description adds no semantics about what 'org' represents (e.g., organization slug or name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List all teams in an organization' and includes the returned fields (slug, name, privacy, parent). This distinguishes it from sibling tools like list_team_members or list_repositories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, filters, or when not to use it. Simple statement without differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait disclosed is the 404 response meaning unprotected branch. No annotations are present, so the description carries the burden. It fails to mention read-only nature, permission requirements, or potential errors like missing branch vs no protection (both 404). Significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence and a parenthetical note. No superfluous content; information is front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameter descriptions, the description is insufficient for an agent to fully understand the tool's behavior. It lacks explanation of return structure, error handling beyond 404, and usage context. With 3 parameters and minimal guidance, completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage). The description does not clarify parameters beyond their names, which are self-explanatory (owner, repo, branch). The default for branch is already in the schema, so no added value. Agents need more context on valid values or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'branch-protection configuration for a branch'. The parenthetical clarification (404 -> unprotected) adds useful context. However, it slightly overlaps with the return value interpretation rather than purely the action, and could be more specific about the configuration details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading branch protection but does not explicitly state when to use this tool versus alternatives like set_branch_protection. No exclusions or prerequisites are mentioned, leaving the agent to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read operation but does not explicitly state it. Lacks details on rate limits, authentication, pagination, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool with one parameter and an output schema. However, it could mention pagination or response format, but given the output schema exists, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'org' with 0% schema description coverage. The description does not explain what 'org' means (organization name/ID) or provide any extra context beyond the schema field title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'organization-level webhooks', and the scope 'events, active state, target URL'. It effectively distinguishes from sibling tools like get_org_audit_log or list_teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, limitations, or contexts where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden of behavioral disclosure. It only states the basic function but does not mention pagination, rate limits, required permissions, or whether the list includes inherited team access. The presence of an output schema is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently communicates the core function without any unnecessary words or structure. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with an output schema, the description is adequate but minimal. It tells what the tool does but lacks parameter explanations and usage context. Could be improved with notes on parameter resolution or output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool's description provides no additional context for the parameters (org and team_slug). While parameter names are self-explanatory, there is no guidance on how to obtain team_slug or any specifics about valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (repositories a team can access), and adds the extra detail of including the team's permission on each. This distinguishes it from siblings like list_repositories or list_repo_collaborators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_repositories (which lists all org repos) or list_team_members. No prerequisites or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It fails to disclose behavioral traits like pagination, sorting, rate limits, or required permissions beyond listing states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two short sentences with no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (reducing need to describe return values), the description omits important context like pagination behavior, sorting options, or filtering beyond state. This is a notable gap for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some value by specifying state enum values ('open | closed | dismissed | fixed'), but it does not provide semantic meaning for 'repo' and 'owner'. With 0% schema coverage, more parameter detail is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'CodeQL/code-scanning alerts', and the scope 'for a repo'. It also lists possible state values, making it distinct from siblings like 'list_secret_scanning_alerts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only lists states but does not explain when to choose this over other alert listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states a simple read operation, but does not mention any side effects, rate limits, or authentication requirements beyond what is implied by the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. The first sentence defines the purpose, and the second lists the affiliation options. No unnecessary words, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not explain return values. However, it lacks mention of pagination, sorting, or any call limits. For a simple list tool, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for the 'affiliation' parameter by listing possible values. However, 'owner' and 'repo' remain undocumented in both schema and description, though they are self-explanatory. The partial compensation raises the score from baseline 1 to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'collaborators on a repo', and specifies the output includes 'permission level'. This distinguishes it from sibling tools like 'list_team_members' which list team members rather than repo collaborators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_repo_permission' or when not to use it. The description lacks any context on prerequisites or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly indicates a read-only list operation but does not disclose potential behavioral traits such as pagination, rate limits, or what happens if no rulesets exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 12 words with no redundancy; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema to describe return values, but the description lacks parameter guidance and usage context. For a simple list tool with one required parameter, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the sole required parameter 'org', failing to explain its purpose or format (e.g., organization name or slug).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List', the resource 'organization-level rulesets', and adds a parenthetical explanation ('the modern, scalable branch-protection model') that distinguishes it from sibling tools like get_branch_protection and get_org_ruleset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing org rulesets as a modern alternative but does not explicitly say when to use this tool versus alternatives like get_org_ruleset or get_branch_protection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the state parameter with allowed values, but lacks details on pagination, rate limits, or behavior when no alerts exist. With no annotations, this is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The state enumeration is front-loaded and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, reducing the need to describe return values. However, the description could mention the scope (per repo) or pagination. Still, it is mostly complete for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning but only explains the state parameter. Owner and repo are left unelaborated, which is insufficient for a 0% coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Dependabot vulnerability alerts, distinguishing it from sibling tools like list_code_scanning_alerts and list_secret_scanning_alerts. The inclusion of state options adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_code_scanning_alerts. No exclusions or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the write nature and a blocking condition. However, it does not explain how existing permissions are handled, confirmation or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences and a list of permission values. Every sentence is relevant and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and incomplete parameter explanations, the description lacks behavior details like return value, error handling, or effect on existing permissions. Missing info for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description only elaborates on the 'permission' parameter with allowed values. Other 4 parameters (org, team_slug, owner, repo) remain unexplained, failing to compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'grant or update' and resource 'team's permission on a repo'. Additionally labels it as 'WRITE OPERATION', distinguishing it from read-only tools like get_repo_permission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions a prerequisite regarding the READ_ONLY flag but does not specify when to use this tool vs alternatives like set_repo_collaborator_permission or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool retrieves a definition, which implies a read operation, but does not disclose any behavioral traits such as idempotency, error handling, rate limits, or authentication requirements. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. Every word adds value, with no redundancy or filler. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two required parameters and no output schema, the description provides the essential purpose. However, it omits details about the return value (e.g., the structure of the ruleset definition) and potential prerequisites. It is adequate but not fully complete for an agent to invoke confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema has no descriptions for 'org' or 'ruleset_id'. The description does not compensate by explaining the parameters' meanings or how to obtain them (e.g., org is the organization name, ruleset_id is a numeric identifier). The parameter semantics are left to the parameter names, which may be ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the target resource ('full definition of a single org ruleset'), and specifies the components included ('rules, conditions, bypass actors'). This distinguishes it from sibling tools like list_org_rulesets, which likely returns a summary list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need the full definition of a specific ruleset) but does not provide explicit guidance on alternatives or when not to use it. Siblings like list_org_rulesets are not mentioned, leaving the agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that it is a read operation and lists possible return values, but it does not mention authentication requirements, rate limits, or behavior for invalid inputs. For a simple read tool, this is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence of 12 words, front-loaded with the core purpose. No wasted words; every part contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 3 self-explanatory params, the description covers the basics: what it does and what it returns. However, it could be more complete by noting authentication dependencies (e.g., requires repo access) or error handling. For a simple read tool, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the parameter names ('owner', 'repo', 'username') are self-explanatory. The description does not explain each parameter beyond the tool's purpose, but in the context of GitHub APIs, these names are clear. However, it would benefit from confirming that 'username' is the GitHub username.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the target ('a user's effective permission level on a repo'), and the possible return values ('admin/write/read/none'). It distinguishes this tool from sibling tools like 'set_repo_collaborator_permission' and 'list_repo_collaborators' by focusing on a single user's permission retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking a single user's permission, but it does not provide explicit guidance on when to use this tool versus alternatives like 'list_repo_collaborators' (which lists all collaborators) or when not to use it (e.g., for non-existent users). No exclusions or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it is a write operation and blocked under read-only mode, but does not detail side effects, required permissions, or idempotency. With no annotations provided, the description carries the full burden but is lacking in depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and a list. It is front-loaded with the purpose, and every line adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema. The description explains the resolution parameter but omits explanations for owner, repo, alert_number, and comment. For a moderate-complexity tool, this is incomplete, though the core action is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the possible values for the 'resolution' parameter (false_positive, wont_fix, revoked, used_in_tests) and provides usage context. However, it does not explain the other parameters (owner, repo, alert_number, comment), and the schema coverage is 0%, so the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a secret-scanning alert and explicitly marks it as a WRITE OPERATION. This distinguishes it from sibling tools like list_secret_scanning_alerts, which are read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool after the credential has been revoked/rotated and notes it is blocked unless GITHUB_MCP_READ_ONLY=false. While it does not explicitly compare to alternatives, the guidance is sufficient given no sibling tool performs the same action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It states the operation type (write) and lists multiple behaviors: requires PR approvals, optional code owner review, blocks force-push/deletion, requires conversation resolution and linear history. It also mentions the environment variable gate. It does not clarify whether the policy replaces or merges with existing rules, but the 'baseline' term implies a fresh set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose in the first sentence. It uses a separate line for the operation type and the condition. Every sentence adds value, though a structured list of effects might improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers the main purpose and effects but lacks parameter details and return value. It provides enough for a basic use case but insufficient for optimal tool usage in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only partially maps parameters: mentions 'required_reviews' and 'require_code_owners' (though ambiguously calling it 'optional'), but omits 'enforce_admins', 'branch', and the meanings of defaults. Does not explain that 'branch' defaults to 'main' or that 'enforce_admins' applies to admins. This leaves significant gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Apply a baseline branch-protection policy', specifying the action (apply), object (branch protection), and scope (baseline). It distinguishes from the sibling tool 'get_branch_protection' which is for reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly flags it as a WRITE OPERATION and warns it's blocked unless GITHUB_MCP_READ_ONLY=false, providing clear when-to-use and when-not-to-use guidance. However, it does not explicitly name alternatives like 'get_branch_protection' for reading, leaving inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that this is a write operation and is blocked under read-only flag. It lists valid permission levels. It does not detail authentication requirements or behavior on update vs add, but provides sufficient transparency for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (3 sentences) and front-loaded with the purpose. However, it lacks structure (e.g., bullet points) and could be more organized, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description covers core behavior and one parameter but omits details for other parameters and return value. It is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Only the 'permission' parameter is explained with valid values. The other three parameters (owner, repo, username) are not described, leaving ambiguity (e.g., is username the collaborator or owner?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Add or update a collaborator's permission on a repo', which is a specific verb-resource pair. It distinguishes from siblings like get_repo_permission (read) and set_team_repo_permission (team vs collaborator).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Declares 'WRITE OPERATION' and 'Blocked unless GITHUB_MCP_READ_ONLY=false', providing when-not-to-use guidance. However, it does not explicitly compare with sibling set_team_repo_permission, though the name differentiates collaborator vs team.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It mentions 'arbitrary' queries, implying flexibility and potential for mutations, but does not specify safety constraints, rate limits, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The primary action is front-loaded, and each sentence adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with two parameters and no output schema, the description is fairly complete. It explains the tool's role and a typical use case, though it could mention that the API is GitHub-specific and that queries can include mutations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds context that 'query' is a GraphQL query string and 'variables' is optional, but does not describe format or constraints for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run an arbitrary GraphQL query') and the specific resource ('GitHub's v4 API'), distinguishing it from sibling tools that are more specific in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case for nested fetches, implying when this tool is beneficial. However, it does not explicitly state when not to use it or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses the auth requirement, phrase syntax, and include parameter options. However, it does not mention rate limits, pagination, or behavior for empty results—information useful for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three lines) and front-loaded with the main action. It covers auth, then parameter explanations. A slightly more structured format (e.g., using colons or bullet points) could improve readability, but it remains clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values need not be detailed), the description addresses the core purpose, auth, and param semantics. It lacks specifics on query scoping (e.g., time range, limit) and potential errors, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the phrase parameter's GitHub audit-log search syntax with an example and listing possible values for include (web, git, all). This adds crucial meaning beyond the schema's basic type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries an organization's audit log. It specifies the resource (organization) and action (query), differentiating it from sibling tools that handle other data like branch protection, rulesets, and repositories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the required authentication (org-owner token with read:audit_log), which is a key usage guideline. It does not explicitly state when to use vs. alternatives, but since no other sibling tool accesses audit logs, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description covers prerequisites and state filtering, but lacks details on pagination, rate limits, or what happens when no alerts are found. The output schema may supplement return value details, but behavioral traits like potential delays or errors are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word adds value. It is concise without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description covers purpose, scope, state, and requirements. With an output schema available, it is largely complete. Minor omissions like pagination handling are acceptable for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains that repo is optional for org-level listing, state can be open or resolved, and owner is required. This adds meaningful context beyond the schema's bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists secret-scanning alerts, distinguishing between repo-level and org-level by omitting the repo parameter. This sets it apart from sibling tools like list_code_scanning_alerts or list_dependabot_alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for use: it lists alerts for a repo or org, with state filter options (open/resolved), and mentions prerequisites (GHAS enabled, token access). However, it does not explicitly exclude other tools or provide alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return format ('trimmed repo records') and fields, implying a read operation. But it does not explicitly state safety (read-only), authentication needs, rate limits, or potential side effects. While the content suggests a safe list, the lack of explicit behavioral disclosure lowers the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for purpose and one for parameter/return details. No redundant information, no fluff. It is front-loaded with the main action and efficiently packed with necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (listing repos with three parameters), the description covers all essential aspects: purpose, parameter semantics, and return fields. The presence of an output schema does not relieve the description of explaining what is returned, and it does so adequately. For the complexity level, it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the JSON schema lacks descriptions. The tool description compensates fully: it explains each parameter (owner, owner_type, type_filter) with clear semantics and acceptable values, and also describes the return fields. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource: 'List repositories for an org or user.' This immediately distinguishes it from sibling tools like get_repository (single repo), list_team_repos (team repos), and others that focus on branches, secrets, or pull requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the parameters and their role (owner, owner_type, type_filter), giving context for usage. However, it does not explicitly state when to use this tool vs alternatives (e.g., get_repository for a single repo, or list_org_webhooks for webhooks). The sibling list is available but not leveraged in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ghe-mcp-gateway MCP server](https://glama.ai/mcp/servers/mholzinger/ghe-mcp-gateway/badges/card.svg)](https://glama.ai/mcp/servers/mholzinger/ghe-mcp-gateway)

Score Badge

Copy to your README.md:

[![ghe-mcp-gateway MCP server](https://glama.ai/mcp/servers/mholzinger/ghe-mcp-gateway/badges/score.svg)](https://glama.ai/mcp/servers/mholzinger/ghe-mcp-gateway)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mholzinger/ghe-mcp-gateway'

If you have feedback or need assistance with the MCP directory API, please join our Discord server