GitHub MCP Server

Server Quality Checklist

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

Latest release: v0.1.5
Disambiguation5/5
Each tool targets a distinct resource or operation: issues (create, get, list, close, batch update, batch add labels), milestones (create, list), PRs (create, get, update, merge), and CI (check status, get logs). No two tools have overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., close_issue, create_milestone, get_ci_logs). Batch operations are prefixed with 'batch_', and names are descriptive without mixing conventions.
Tool Count5/5
15 tools is a well-scoped set for a GitHub MCP server. It covers core workflows without being overly numerous or too sparse, providing a balanced surface for common development tasks.
Completeness4/5
The tool set covers CRUD-like operations for issues, PRs, milestones, and CI monitoring. Minor gaps exist (e.g., no tool for adding comments to issues, managing individual labels, or PR review actions), but the core workflows are well-supported, and agents can work around the gaps.
Average 3.8/5 across 15 of 15 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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 provided, so the description must carry the full burden of behavioral disclosure. It mentions the tool returns specific fields but does not disclose potential errors, permissions needed, rate limits, or behavior for missing issues. Provides only basic return information.
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: first states purpose, second lists return fields. Extremely concise, front-loaded with the action and resource, with no unnecessary 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?
While the tool is simple and has an output schema, the description lacks parameter details and usage context. With 0% schema coverage, it should provide more guidance on parameters and conditions. It misses opportunities to explain owner/repo defaults or error scenarios.
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 input schema has 3 parameters with 0% description coverage. The description adds no information about parameters, such as what 'owner' or 'repo' default to or how they are used. It does not compensate for the lack of schema descriptions.
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 retrieves full GitHub issue details, including body content. The verb 'retrieve' and resource 'GitHub issue' are specific. While it doesn't explicitly distinguish from siblings like 'list_issues' or 'close_issue', the focus on a single issue's details implies a read operation, making it fairly clear.
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 over siblings. It does not mention when not to use it or provide alternatives. Siblings like 'close_issue' or 'list_issues' are contextually available, but the description offers no usage direction.
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 mentions optional inputs and return fields but omits side effects (e.g., notifications, irreversibility) and prerequisites (e.g., issue must be open). This is insufficient for a mutating 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 (a few lines) and front-loads the main action. The bullet list for options is clear, but some space could be used to cover missing parameters. Still, it is well-structured overall.
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 complexity (5 params, no annotations, output schema exists), the description lacks coverage of owner/repo default behavior and preconditions. It mentions return fields briefly, but overall 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?
Schema coverage is 0%, requiring description to compensate. It explains 'comment' and 'state_reason' adequately but omits 'owner' and 'repo' entirely, which are optional but essential for context. This leaves significant gaps.
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 'Close a GitHub issue', specifying the verb and resource. It distinguishes from sibling tools (e.g., get_issue, update_pr) by focusing solely on closing.
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 closing issues with optional comment/reason but does not explicitly state when to use it over alternatives (e.g., update_pr) or mention preconditions like issue being open.
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?
Without annotations, the description does not disclose behavioral traits like idempotency, error behavior on duplicate titles, or rate limits. It only lists optional parameters and return fields.
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 and front-loaded with purpose. Optional parameters and return format are listed efficiently, though structure could be more formal (e.g., bullet points).
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?
Covers optional parameters and return format, but misses owner and repo (even with defaults, they affect usage). No usage guidelines or behavioral notes, leaving gaps for a 6-parameter creation 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?
Schema description coverage is 0%, so description adds value by explaining optional parameters (description, due_date with format, state with default). However, it omits owner and repo parameters, and title lacks extra context beyond 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 explicitly states 'Create a GitHub milestone', which is a specific verb and resource. It clearly distinguishes from sibling tools like list_milestones or create_issues.
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 (e.g., updating a milestone via other tools). Lacks context about prerequisites like specifying owner and repo, which have defaults but are not mentioned.
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 details the output structure and mergeable_state values, but does not explicitly state that the tool is read-only or describe potential errors, auth needs, or rate limits. It is adequate but not exhaustive.
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 sentences plus a short list. It is front-loaded with the purpose and immediately provides the return fields. No extraneous content.
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 description covers the purpose and output structure well, which is important given the output schema is not formalized. However, it completely misses parameter semantics and usage guidelines, leaving gaps for an effective tool invocation. For a simple get tool this is borderline adequate.
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%, meaning the input schema has no property descriptions. The tool description does not explain any parameters (pr_number, owner, repo), their types, defaults, or usage. This is a critical gap for a tool with three parameters.
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 'Get PR details including mergeable status and statistics,' specifying the action (get) and resource (PR details). It differentiates from sibling tools like get_issue (different resource) and merge_pr (different action), making the purpose unambiguous.
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 does not provide any guidance on when to use this tool versus alternatives like update_pr or list_issues. It lacks explicit when-to-use or when-not-to-use information, leaving the agent to infer from context.
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?
Discloses key behaviors: parallel execution, batch limit, replacement behavior for labels/assignees, and return format including success_rate and failed count. No annotations are present, so the description carries the full burden; it does so fairly well, though it could mention idempotency or error handling.
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 concise paragraphs with no redundant information. The core purpose, update object format, replacement note, and return format are all front-loaded. Every sentence 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?
Provides the output schema in the description, which helps. However, it does not cover prerequisites like issue existence, authentication, or the meaning of 'owner' and 'repo' parameters. Given the batch complexity and lack of annotations, it is minimally adequate but has 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?
0% schema coverage means the description must explain parameters. It details the 'updates' array structure but omits explanations for 'owner', 'repo', and 'max_workers' (only implied by 'parallel'). Most parameters lack semantic guidance.
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 the tool updates multiple GitHub issues in parallel with a max batch size. The verb 'update' and resource 'multiple GitHub issues' are specific and distinguish it from siblings like batch_add_labels which only add labels.
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 explicit guidance on when to use this tool versus alternatives like batch_add_labels for label-only updates. The description implies batch updates but does not provide when-to-use or when-not-to-use 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?
Describes return structure and edge case (no runs), but lacks details on side effects (e.g., whether it triggers runs), authentication needs, or rate limits. No annotations to supplement.
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?
Two brief paragraphs: purpose and output format. No fluff, though output format could be omitted if structured schema were provided.
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?
Covers return values, edge case, and basic purpose. Missing explanation of optional parameters and defaults, but with 3 params (1 required), it's mostly adequate.
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 description only mentions 'branch' contextually. 'owner' and 'repo' are not explained at all, leaving the agent guessing about defaults and scope.
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?
Clear verb 'check', specific resource 'CI workflow status for a branch', and differentiates from siblings like get_ci_logs and issue/PR tools.
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?
Implied usage for checking CI status, but no explicit when-to-use, when-not-to-use, or comparisons with alternatives like get_ci_logs.
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?
Describes the return structure with fields for each milestone, providing transparency beyond the input schema. However, lacks details on pagination or authentication requirements.
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?
Extremely concise: one-line purpose followed by bullet-pointed parameter details. No redundant information.
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?
Covers core functionality and return format but omits owner/repo parameter explanations and potential pagination or error handling, considering the tool has 5 parameters and 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?
Adds meaning for three parameters (state, sort, direction) with valid options and defaults, but does not explain owner and repo, leaving them opaque despite low schema 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?
Description clearly states the tool lists repository milestones with filtering and sorting. The verb 'list' and resource 'milestones' are specific and distinguish from sibling tools like create_milestone.
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 explicit guidance on when to use this tool versus alternatives like list_issues or get_issue. The description only lists parameter options without context for selection.
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?
Describes parallelism, required format for project_id, and the return structure (total, successful, failed, etc.). Lacks details on error handling or side effects, but overall transparent for a batch operation.
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?
Five short, focused sentences with no filler. Front-loaded purpose, then requirements, then return format. Each sentence adds 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?
Covers main purpose, key requirements, and return structure. Missing details on optional parameters (owner, repo, max_workers) and potential error scenarios, but overall adequate for a batch tool with output schema.
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 coverage is 0%, so description must compensate. Explains project_id format and lists required parameters but omits semantics for owner, repo, and max_workers. Return structure is useful context.
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 'Link multiple issues to a GitHub Project (v2) board in parallel.' It specifies the verb (Link), resource (issues to Project board), and parallelism, distinguishing it from sibling tools like batch_add_labels.
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?
Implied usage for batch-linking issues, but no explicit when-to-use or when-not-to-use vs alternatives. Mentions project_id format and required token scope, which is helpful for setup.
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 provided, the description carries the full burden of behavioral disclosure. It discloses pagination, default and maximum limits, filtering options, and the returned data structure. However, it does not mention authentication requirements or rate limits, which would be helpful for a tool interacting with GitHub.
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, using a short introductory sentence followed by a bullet-like list of filters and their defaults. It also specifies the return structure. Every sentence adds value, and there is no redundant information. Slightly front-loaded with the purpose.
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 complexity (9 parameters, no annotations, no output schema defined but description includes return structure), the description provides most necessary details for a listing tool. It covers filtering and pagination well. Missing owner/repo/direction and behavioral notes, but overall fairly complete.
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 schema description coverage is 0%, so the description must add meaning. It explains 6 out of 9 parameters (state, labels, milestone, assignee, sort, limit) with defaults and options (e.g., milestone by title not number). However, it misses owner, repo, and direction parameters, which are important for specifying the repository and sort order. This gap reduces completeness.
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 that the tool lists and filters GitHub issues with pagination. The verb 'list' and resource 'GitHub issues' are specific, and the description distinguishes it from sibling tools like 'get_issue' or 'close_issue' which handle individual issues or different actions.
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 when to use the tool (listing/filtering issues) and provides details on optional filters and defaults. However, it does not explicitly state when not to use it or suggest alternative tools for other scenarios. Still, the context is clear enough for an agent to decide.
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 provided, so description bears full burden. It discloses mergeable status check, default delete_branch=true, and method options. However, it omits what happens if mergeable is false (error? no-op?), and lacks details on side effects like PR closure or status updates.
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?
Extremely concise: two sentences plus a bulleted list of options and return format. Every sentence adds value; no redundancy. Front-loaded with core action.
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?
Output shape is provided (merged, sha, etc.), and all parameters described. Lacks prerequisites like user permissions or that PR must be open. For a single-action tool, this is nearly complete but could add a note about required access.
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 describes only types and defaults (0% coverage), but description adds rich semantics: explains merge_method enum values, commit_title/commit_message applicability (squash/merge only), and delete_branch default. Significantly enhances parameter understanding beyond 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 clearly states the verb 'Merge' and the resource 'PR', and adds specificity with 'after checking mergeable status'. This distinguishes it from sibling tools like 'update_pr' or 'create_pr_with_content'.
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 lists options and defaults but does not explicitly guide when to use this tool versus alternatives like 'update_pr' or 'check_ci_status'. Usage context is implied but lacks explicit 'when to use' or 'when not to use' guidance.
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?
The description discloses key behavioral traits: labels are added (not replaced), operations run in parallel, and the return structure is detailed. However, it lacks information on error handling, rate limits, or permissions, which would be beneficial given no annotations.
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 highly concise with three sentences, no filler, and front-loaded purpose. Every sentence adds 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?
The description is largely complete given the tool's complexity, covering operation structure, return fields, and parallel behavior. Missing context on owner/repo and max_workers limits is minor, and output schema covers return values.
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?
With 0% schema description coverage, the description compensates by explaining the structure of the operations array (issue_number and labels required) and noting max_workers default. However, owner and repo are not explained, though they have defaults.
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 'Add labels to multiple issues in parallel' with the clarification that labels are added, not replaced. It distinguishes from sibling tools like batch_update_issues by focusing specifically on label addition.
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?
No explicit when-to-use or when-not-to-use guidance is provided. While the parallel nature is mentioned, there is no comparison to alternatives like batch_update_issues. Usage context is implied but not clarified.
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 provided, so description must carry full burden. It states auto-detection of current branch as head and specifies return fields (pr_number, url, state, etc.), but does not disclose permissions, rate limits, or side effects. It is adequate but not exhaustive.
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 well-structured with clear sections (Required content, Optional, Returns). It is concise—4 sentences plus structured lists—with no extraneous information, and the most important details are front-loaded.
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 8 parameters (4 required) and an output schema, the description covers core usage (required content, optional issue linking, return fields). It lacks explanation for owner/repo defaults (likely current repo) and edge cases like non-default base, but is complete for common use.
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?
With 0% schema description coverage, the description compensates by explaining meaning, length requirements, and defaults for most parameters (problem, solution, key_changes are specified with sentence counts; issue is explained as GitHub issue number). Base, owner, repo are mentioned but add minimal detail beyond schema defaults.
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 'Create a GitHub PR with structured content', which is a specific verb+resource. It distinguishes from sibling tools like create_issues and merge_pr by focusing on PR creation with required structured fields.
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 required and optional content sections, including length guidelines. It implicitly indicates usage for creating a PR with problem-solution-changes, but does not explicitly contrast with alternatives or give when-not-to-use guidance.
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 the burden. It discloses that null values are ignored, that updates are partial, that merged PRs cannot be updated, and specifies the return format. This is thorough for a simple update tool, though it omits permissions or rate limits.
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 short and well-structured: an introductory sentence, a bulleted list of optional updates, a returns line, and a note. Every sentence adds value, and the key purpose is front-loaded.
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 tool's complexity (7 parameters, no annotations, but output schema exists), the description covers core functionality well: update behavior, optional fields, constraint on merged PRs, and return format. Some context is missing (owner/repo, authentication), but it is largely sufficient for correct usage.
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 explains the main optional parameters (title, body, base, state) with their meanings and state values, compensating for the 0% schema coverage. However, it fails to mention the owner and repo parameters, which are present in the schema with defaults but could be important for context.
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 'Update PR metadata' and specifies that only provided fields are updated, distinguishing it from sibling tools like merge_pr (merging) and create_pr_with_content (creating). It lists the optional fields and their meanings, making the purpose explicit.
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 guidance on when to use the tool by stating 'Only provided fields are updated; None values ignored' and 'Cannot update merged PRs.' It implicitly differentiates from siblings through context, but lacks explicit 'use this instead of' statements.
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?
Since no annotations are provided, the description carries the full burden. It explains the tool returns logs, defaults to failure status, and limits lines. It doesn't mention authentication or rate limits, but overall it's transparent about what the tool does.
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 structured with a main sentence, bullet points for parameters, and a return format. It is concise without unnecessary words, though the owner and repo parameters could be briefly explained.
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 7 parameters (0 required) and presence of an output schema, the description covers the key inputs and output. It explains defaults and mutual exclusivity, making it usable, though owner and repo are not fully described.
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%, but the description adds meaning by explaining the mutual exclusivity of branch and run_id, and describing filters like job_name, status, max_lines. It compensates for the lack of schema descriptions, though owner/repo are less explained.
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 retrieves CI workflow logs for debugging failed jobs. It specifies the resource ('CI workflow logs') and the action ('Get'), and distinguishes from sibling tools like check_ci_status by focusing on logs.
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 says to provide either branch or run_id (not both), and lists optional filters with their defaults. This gives clear context for when to use the tool, though it doesn't directly compare to alternatives.
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?
No annotations provided, so description carries full burden. It discloses parallelism with max_workers, return structure with success/failure per issue, and key fields. Lacks rate limit or auth details, but adds significant behavioral context.
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 digestible paragraphs with clear structure: purpose, fields, options, return type. No wasted words, front-loaded with key action.
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?
Covers required fields, optional fields, parallel execution, and return format. Output schema exists so return is explained. Missing default behavior of owner/repo, but sufficient for typical use.
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 coverage is 0%, but description adds meaning to all parameters: specifies issues array format (title required, body, labels, milestone, assignables) and max_workers options. Owners and repo have defaults but not explained; still strong value.
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 'Create GitHub issues (1 or more)' with a focus on parallel execution. It distinguishes from sibling tools like close_issue or list_issues by emphasizing bulk creation.
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 hints at use for bulk creation with parallelism but does not explicitly state when not to use or contrast with siblings like batch_update_issues. It provides clear context but lacks exclusions.
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:

[![github-mcp-server MCP server](https://glama.ai/mcp/servers/rriesco/github-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/rriesco/github-mcp-server)

Score Badge

Copy to your README.md:

[![github-mcp-server MCP server](https://glama.ai/mcp/servers/rriesco/github-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/rriesco/github-mcp-server)

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/rriesco/github-mcp-server'

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