github-devhub-mcp

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 and action—PRs, issues, repos, code search, CI, and AI analysis are cleanly separated. Even overlapping AI tools (summary vs review vs triage) have clearly defined different outputs.
Naming Consistency4/5
Most tools follow a verb_noun pattern (get_pr, create_issue, list_repos, summarize_pr) with domain prefixes. Minor exceptions like ci_status and health are noun phrases, but the overall pattern is consistent and predictable.
Tool Count4/5
17 tools is slightly above the ideal range, but each tool serves a distinct purpose in the GitHub + AI workflow. No redundant tools; the count feels intentional even if a bit heavy.
Completeness3/5
The surface is strong for reading and analyzing (repos, issues, PRs, code, CI) and supports creating issues and comments. However, there are no update/delete/merge operations for issues or PRs, leaving common management workflows incomplete.
Average 3.7/5 across 17 of 17 tools scored.
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 status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It does disclose that the tool fetches the diff, commits, and description, which implies data access beyond the provided parameters. However, it does not mention that the operation is read-only, potential latency or cost, or any limitations on review scope.
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 that conveys the core purpose and a useful detail about fetched data. No filler or redundant content.
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 five parameters and no schema descriptions, the description is insufficient for an agent to understand parameter semantics, especially 'focus' and 'max_files'. It also lacks guidance on when to use this tool over similar PR-related tools. The presence of an output schema helps but does not make up for these gaps.
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 schema has zero descriptions for parameters, and the description does not compensate. While owner, repo, and pull_number are self-explanatory by name, 'focus' and 'max_files' are left undefined. The description only hints at what data is fetched, not how parameters shape the review.
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's function with a specific verb ('Run') and resource ('LLM code review on a pull request'). The parenthetical 'fetches the diff, commits, and description' adds useful scope and distinguishes it from sibling tools like github.get_pr which only fetches PR metadata.
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?
Usage context is implied: an agent should use this when an LLM code review is needed. However, there is no explicit comparison to ai.summarize_pr or guidance on when to choose one over the other, nor any stated alternatives 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 are provided, so the description must disclose behavior. It mentions filtering by state and labels, but fails to disclose pagination (page, per_page), sorting (sort), default state 'open', or that it returns a list. These are important for an agent to correctly invoke the tool and interpret results.
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 sentence that efficiently conveys purpose and key filtering capability. No filler or redundant information.
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 7 parameters, no annotations, and no schema descriptions, a short sentence is insufficient. It omits pagination behavior, sorting options, default states, and label formatting, making it incomplete for reliable use by an agent.
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 explains only 'state' and 'labels' (as filters), but leaves page, per_page, sort, owner, and repo without additional semantic context. The schema itself only provides titles and defaults, so many parameters remain underspecified.
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's function: 'List issues in a repository'. The verb 'list' and resource 'issues' distinguish it from sibling tools like github.get_issue (singular) and github.list_prs (pull requests), and the mention of filtering by state and labels adds scope.
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 issues with optional filtering, but does not explicitly state when to choose this tool over alternatives such as github.get_issue or github.list_prs. No when-not-to-use or alternative references are provided, so guidance is only implicit.
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 carries the full burden of behavioral disclosure. It only says 'Get ... with metadata,' which vaguely implies a read operation, but does not explicitly state that it is read-only, what metadata is returned, or any error/edge-case behavior. This is a significant gap.
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 sentence, front-loaded with the verb and resource, and contains no fluff. Every word earns its place.
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 and the presence of an output schema, the description is adequate but not complete. It distinguishes from PRs but does not address potential use cases or alternatives further. The 'with metadata' phrase is vague, and the lack of annotations leaves behavioral aspects uncovered.
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 reinforces 'issue_number' via 'by number' but does not explain 'owner' or 'repo' or any parameter constraints or formats. The parameter names are self-explanatory, but the description adds little value beyond the 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 action 'Get' and the resource 'issue', and explicitly distinguishes from PRs by saying 'not a PR', which differentiates it from github.get_pr. This is a specific and unambiguous purpose.
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 that this tool is for issues rather than PRs, but it does not explicitly name alternatives like github.get_pr, github.list_issues, or github.create_issue. The guidance is present but only implicit.
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 carries the transparency burden. It enumerates the returned metadata fields, giving useful insight into the output scope. However, it omits details on authentication requirements, rate limits, or error behavior (e.g., repository not found).
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, concise sentence with a colon-separated list. It is front-loaded with the action and includes concrete details without any fluff or repetition.
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 operation with an output schema, the description is minimally adequate. It lacks usage guidance and parameter clarity, but the output schema likely covers return details. The description could be improved by adding when-to-use context and clarifying parameter formats.
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 does not explain the parameters (owner, repo), leaving ambiguity about expected formats (e.g., whether owner is a username or organization). The parameter names are self-evident, but no additional semantics are provided.
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 repository metadata' and lists specific metadata fields (description, language, stars, default branch, archived status). This distinguishes it from sibling tools like get_pr (pull request metadata) and list_repos (multiple 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 explicit guidance on when to use this tool versus alternatives. It does not mention when to prefer get_repo over list_repos or get_pr, nor does it provide exclusions or use-case context.
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 the full burden of behavioral disclosure. It only states the output content and does not clarify that this is a read-only AI operation, mention authentication or any side effects, or describe failure modes for missing PRs.
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 core action and content scope. No unnecessary words or repetition are present.
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 presence of an output schema, the return format is covered elsewhere. The description clearly states the purpose and summary content, and the required parameters are evident from the schema. It lacks notes on edge cases or prerequisites, but for a simple summarization tool this is 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 adds no parameter-related meaning. The names owner, repo, and pull_number are self-explanatory, but the description does not explicitly map them to the target PR or provide any additional format/constraint information.
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 uses a specific verb ('Produce a concise summary') and names the resource ('a pull request') plus the content scope ('what it does, how, and notable changes'). This clearly distinguishes it from sibling tools like github.get_pr (raw PR data) and ai.review_pr (evaluation).
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 summarizing a pull request but does not explicitly state when to use this tool instead of alternatives such as github.get_pr or ai.review_pr. No exclusions or alternative context are provided.
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 carries the full burden of behavioral disclosure. It only states a high-level action ('summarize') but does not mention that the operation is read-only, any permission requirements, output format, or edge cases (e.g., no comments). This is a significant gap for a tool with no annotation safety hints.
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 with no filler. Every word contributes to understanding the tool's purpose and audience, making it highly concise and well-structured.
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 3-parameter tool with an output schema, the description is minimally adequate. However, the lack of annotations and absence of any behavioral nuance (e.g., read-only nature, response type) leaves the agent without a complete picture. The output schema covers return values, but behavior and safety are under-specified.
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 does not compensate by explaining the parameters. The parameter names (owner, repo, issue_number) are self-explanatory, but the description adds no meaning beyond the schema, leaving the agent to infer how they relate to the summarization task.
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 uses a specific verb ('summarize') and a clear resource ('issue and its comment thread'), and the purpose ('so a newcomer can jump in') adds context. It is clearly distinct from siblings like github.get_issue (fetches raw issue) and ai.summarize_pr (summarizes pull requests, not issues).
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 phrase 'so a newcomer can jump in' indicates when the summary is useful, giving a clear usage context. However, it does not explicitly name alternatives or state when not to use this tool (e.g., when raw issue data is needed), though the purpose makes it fairly obvious.
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 burden of behavioral disclosure. It reveals the outputs (classification and explanation) but does not mention whether the tool modifies anything, how decisions are made, or confidence levels. This is acceptable for a read-only classifier 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 sentence, front-loaded with the action ('Classify an issue') and concise, covering the main purpose and outputs without unnecessary filler.
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 tool with three simple parameters and an output schema, the description covers the core function and outputs. However, it lacks explicit usage guidance and parameter semantics, which are important for an AI agent to invoke it correctly in all contexts.
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 adds no parameter details. Although parameter names (owner, repo, issue_number) are self-explanatory, the description does not elaborate on their roles, constraints, or how they relate to the classification task.
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's function: classifying an issue and specifying outputs (type, priority, suggested labels) and explanation. This distinguishes it from sibling tools like ai.summarize_issue, which focus on summarization rather than classification.
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?
Usage guidance is implied by the verb 'classify' and the issue context, but the description does not explicitly state when to use it versus alternatives like ai.summarize_issue or github.get_issue. No exclusions or alternative calls are 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 burden. It accurately states the core behavior but fails to disclose pagination behavior, the default state (open), or that it is a read-only operation. These details are left to the schema, which is minimal, making the transparency adequate but incomplete.
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 concise sentence, front-loaded with the primary action. It contains no filler or redundant information, making it very 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?
The tool is simple and an output schema exists, but the description leaves gaps about valid state values and pagination parameters (page/per_page). The defaults in the schema partially compensate, yet an agent may still struggle with correct invocation without further guidance.
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 clarifies the 'state' parameter via 'filtered by state,' but leaves owner, repo, page, and per_page without semantic explanation. The description does not meaningfully help an agent understand these 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 the tool's purpose: 'List pull requests in a repository, filtered by state.' It uses a specific verb (List), resource (pull requests), scope (repository), and filter (state), which distinguishes it from sibling tools like get_pr that retrieve a single PR.
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 provides clear context for when to use the tool (listing PRs in a repo) but does not explicitly mention alternatives or exclusions, such as 'use get_pr for a single PR' or 'use list_issues for issues only.' Usage is implied rather than explicitly guided.
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. It mentions 'sorted and paginated', which is a behavioral trait, but doesn't disclose details like default sort order, pagination semantics, authentication requirements, or read-only nature. This is minimal transparency for a tool with 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 a single, concise sentence that front-loads the primary action and scope. No fluff or redundancy, every word earns its place.
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 is a simple list operation with an output schema (not shown), so the description doesn't need to explain return values. However, it lacks details on authentication, public vs private repos, or pagination limits. It's adequate but with gaps in usage context that could affect correct invocation.
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 references 'owner', 'sorted', and 'paginated' vaguely, without explaining the parameters' meanings, valid sort values, or pagination configuration. The parameter names are self-explanatory, but the description adds little beyond that.
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's function: 'List repositories for an owner (user or org)', using a specific verb and resource. It distinguishes from siblings like get_repo (single repo) and list_prs (pull requests) by specifying the resource type and 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 gives clear context on when to use: listing repositories for a given owner. It doesn't explicitly mention alternatives, but the scope is unambiguous given the sibling tools. It lacks explicit exclusions but provides sufficient context for an agent to select it for repository listing tasks.
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 full responsibility. It clearly states that the tool consumes a pull request's commits and changed files to generate a message, which implies a read-only analysis and no side effects. However, it does not explicitly mention permissions, rate limits, or that no modifications are made to the PR, leaving some behavioral uncertainty.
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 entire description is a single, front-loaded sentence with no redundant words. It states the action and the source data efficiently.
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 simplicity—3 self-explanatory parameters and an output schema—the description covers the core functionality. It mentions the input (PR commits and changed files) and the output type (conventional commit message). It could benefit from a note on when to use it or prerequisites, but these are already scored in other dimensions.
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 input schema provides only parameter names with zero descriptions. The description connects the parameters to 'a pull request,' implying that owner, repo, and pull_number identify the target PR. This adds some semantic context, but it doesn't explain each parameter's format or constraints beyond what their names suggest.
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 uses the specific verb 'Generate' and clearly identifies the resource ('a conventional commit message') and the source ('a pull request's commits and changed files'). This distinguishes it from sibling tools like ai.summarize_pr and ai.review_pr, which have different outputs.
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 intended use case—when a commit message is needed from a PR—but does not explicitly contrast with alternatives like ai.summarize_pr or provide when-not-to-use guidance. The niche is clear, but no explicit usage boundaries are given.
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 provided, the description carries full responsibility for behavioral disclosure. It mentions the token scope requirement, which is valuable context, but does not address rate limits, pagination behavior, or search syntax limitations.
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 succinct sentences: the first states the purpose, the second provides a necessary authentication detail. No wasted words, information is front-loaded.
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 is relatively simple, and the description covers the core purpose and a key prerequisite (token scope). However, it omits guidance on search query syntax (e.g., qualifiers) and any rate limit or pagination behavior, leaving gaps that the schema cannot fill due to its lack of descriptions.
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, but it fails to explain the query, page, or per_page parameters. The query's purpose is only implicitly derived from the tool name/description, and pagination parameters are entirely unaddressed.
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 uses the specific verb 'search' and the resource 'code across GitHub', clearly indicating the operation. It distinguishes itself from sibling tools like github.get_pr and github.list_issues, which operate on different GitHub resources.
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 clear prerequisite (token with specific scope) and implies its use for code search. While it doesn't explicitly mention alternatives, the tool is uniquely positioned among siblings for this purpose, giving clear 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states that dry_run=true previews the request without writing anything, revealing that the default action writes. However, it does not disclose authentication needs, side effects, or error handling, leaving some gaps.
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 long, front-loading the core action and then adding the dry_run caveat. It contains no filler or redundant phrasing, making it highly 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?
For a simple mutation tool, the description is adequate but minimal. It omits context about required repository parameters, potential failure modes, and the relationship to other issue operations. The output schema covers return values, so this is not a critical gap, but the description alone leaves some context unspecified.
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 explains dry_run, while owner, repo, title, body, and labels receive no added meaning beyond their names. The names are self-explanatory, but the description fails to provide any additional semantic context for these 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 opens with 'Create an issue,' which is a specific verb+resource statement. It clearly distinguishes this tool from siblings like get_issue and list_issues, which are read operations. The dry_run note is an additional clarification without obscuring the primary purpose.
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 when an issue needs to be created, but it does not explicitly contrast with alternatives (e.g., add_issue_comment for comments). There is no 'when-not' guidance or mention of prerequisite conditions like repository ownership.
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 carries the full burden of behavioral disclosure. It does reveal the dry_run behavior (preview without writing) which adds transparency. However, it does not explicitly state that posting a comment is a permanent write action, mention authentication requirements, or describe any side effects beyond the write itself.
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 concise sentences, front-loaded with the primary action and immediately followed by the most relevant behavioral nuance (dry_run). Every word earns its place with no 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 an output schema, and no annotations. The description covers the core purpose and dry_run, but lacks explicit usage guidance, alternative distinctions, and deeper behavioral context such as auth or side effects. For a simple mutation tool this is adequate but not exceptionally 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?
Schema coverage is 0% (no parameter descriptions in the schema). The description adds meaning for dry_run ('preview without writing') and clarifies that 'issue_number' can refer to a PR thread. However, it does not explain body, owner, or repo, leaving the agent to infer their roles from standard GitHub knowledge.
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 uses a specific verb ('Post') and clearly identifies the resource ('a comment on an issue or PR thread'). It unambiguously distinguishes this tool from siblings like create_issue and get_issue by focusing on commenting on existing threads.
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 clear context that this tool is for posting comments on issue or PR threads, and it highlights the dry_run option as a preview mode. It does not explicitly name alternatives or exclusions, but the purpose is so specific that the intended usage is clear.
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. It discloses exactly which data will be returned (title, state, author, stats, head/base refs), making the read-only behavior clear. It omits details like authentication or error behavior, but those are less critical for a simple GET.
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 sentence, front-loaded with the action ('Get full detail'), and every word contributes to conveying the tool's purpose. There is zero filler or redundancy.
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 low complexity, the combination of the description, the self-explanatory parameters, and the presence of an output schema is nearly complete. The description states what is returned, and the output schema defines the structure. It could mention that it returns a single pull request object, but this is not a significant gap.
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 provides no explanation of owner, repo, or pull_number. Although the parameter names are highly self-explanatory in the GitHub context, the description adds no semantic value 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 uses the specific verb 'Get' and resource 'pull request', and enumerates the exact fields returned (title, state, author, stats, head/base refs). This clearly differentiates it from sibling tools like list_prs (list) and get_issue (issue).
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 phrase 'full detail' implies this tool is for fetching a single pull request in depth, but it does not explicitly contrast with alternatives like github.list_prs or github.get_issue, nor does it state when not to use it. Usage is implied rather than explicit.
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 of disclosing behavior. The verb 'Get' clearly indicates a read-only operation, and the phrase 'check runs + combined commit status' explicitly states what data is returned. It does not mention authentication requirements or edge cases, but for a read-only getter this is adequate.
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 with no wasted words. It conveys the core purpose, target scope, and included data types in under 20 words.
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, so return values are covered by structured data. The description provides the essential context: what the tool does, when to use it, and the target types. It omits edge cases like providing both pull_number and ref, but given the schema coverage, the description is largely 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 description adds semantic meaning by clarifying that the tool works 'for a PR or a commit ref', which maps to the optional pull_number and ref parameters. However, it does not explain that owner/repo are required, nor does it address the relationship between pull_number and ref (e.g., mutual exclusivity). With 0% schema coverage, this is only partial compensation.
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 operation ('Get CI status') and the specific resource ('check runs + combined commit status') with a defined scope ('for a PR or a commit ref'). This sharply distinguishes it from sibling tools like github.get_pr, which fetches PR details, and github.list_issues, which lists issues.
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 clear usage context by specifying two target types: PR or commit ref. Although it does not explicitly name alternative tools or say 'use this instead of X', the scope is precise enough for an agent to select this tool when CI status is needed.
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 are provided, so the description carries the burden. It discloses that the tool performs network checks against GitHub and Groq, which is meaningful behavioral context. However, it does not explicitly state that it is read-only or describe potential error handling if services are unreachable, though the health-check nature implies safety.
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 sentence, directly starts with the main purpose, and includes only essential details. Every word earns its place, with no redundancy or fluff.
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 tool is simple (zero parameters, health check), and the description covers the core functionality. An output schema exists, so return values need not be described. While it could mention that this is a read-only diagnostic, the description is sufficient for the tool's low complexity.
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?
The input schema has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameters, as there are none. The description adds no parameter information, but none is required.
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 'Check connectivity' and names specific resources (GitHub API rate limit and live Groq LLM ping). This clearly differentiates from sibling tools that operate on GitHub PRs/issues or AI summaries, so the purpose is 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 implies usage for connectivity checks but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. No guidance is given on when not to use it, so it relies on the agent to infer context from the tool name and sibling group.
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. It explicitly states the data sources (README and top-level file tree) and the nature of the output (an onboarding brief). 'Generate' implies a non-destructive read-only operation, giving sufficient transparency for an AI agent. It lacks explicit auth or rate-limit caveats, but these are not central for a generation tool.
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 conveys all necessary information without fluff. Every word earns its place, making it easy to parse and act upon.
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 simple input schema (owner/repo) and the presence of an output schema, the description is complete. It explains what the tool does, from what inputs, and the output type. No additional context about return values is needed since an output schema exists. The tool's scope is fully clarified.
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 does not explicitly describe the owner and repo parameters, but their names are self-explanatory within the GitHub context. The description's mention of 'repository' indirectly anchors the parameters, but it could be more explicit about how owner and repo identify the target. This is adequate but not outstanding.
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 generates an onboarding brief for a repository using its README and top-level file tree. The verb 'Generate' is specific, and the resource ('repository') is clearly defined. It differentiates itself from sibling tools like github.get_repo and ai.summarize_pr by focusing on newcomer onboarding.
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 phrase 'newcomer's onboarding brief' provides clear context for when to use this tool—when introducing someone to a repository. While it doesn't explicitly mention alternatives or exclusions, the use case is well-understood and distinct from siblings like code search or PR review.
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:

[![mcp_project MCP server](https://glama.ai/mcp/servers/VINITVINAY-Tech/mcp_project/badges/card.svg)](https://glama.ai/mcp/servers/VINITVINAY-Tech/mcp_project)

Score Badge

Copy to your README.md:

[![mcp_project MCP server](https://glama.ai/mcp/servers/VINITVINAY-Tech/mcp_project/badges/score.svg)](https://glama.ai/mcp/servers/VINITVINAY-Tech/mcp_project)

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/VINITVINAY-Tech/mcp_project'

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