MCP Toolkit Pro

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes: code analysis, task list creation, and the various GitHub read/search operations. The only potential confusion is between github_read_file and github_readme, since readme is a special case of file reading, but the descriptions make the distinction clear enough.
Naming Consistency3/5
GitHub tools consistently use a 'github_' prefix followed by a verb_noun pattern (e.g., github_search_repos, github_list_issues), but the two non-GitHub tools (analyze_code, create_task_list) lack any prefix. This mixed convention — some tools namespaced, others not — reduces naming consistency.
Tool Count4/5
With 7 tools, the set falls comfortably within the ideal 3-15 range. The count feels reasonable for a server that covers both general utility functions and GitHub-specific operations, though it could be seen as slightly sparse for a 'Toolkit Pro' label.
Completeness2/5
The GitHub toolset is read/search-only, lacking any create, update, or delete operations for issues or PRs. The task list tool only supports creation, with no way to update or delete tasks, creating dead-ends in workflows. For a general-purpose toolkit, the absence of write operations and task lifecycle management represents significant gaps.
Average 3.7/5 across 7 of 7 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
- Last stable release on July 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 carries the full burden. It only mentions the returned fields and does not disclose read-only behavior, authentication requirements, pagination, or default state handling beyond what the schema already states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no waste. The first sentence states the purpose, the second lists the key return fields, making it concise and 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 a simple list operation with all parameters documented in the schema. However, the description lacks differentiation from similar tools and does not mention default state or result limits, leaving some contextual gaps.
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 100%, with each parameter clearly documented. The description adds no extra parameter-level meaning, so the baseline score of 3 is appropriate.
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 'List issues in a GitHub repository' with a specific verb and resource. It does not explicitly distinguish itself from the sibling github_list_prs, but the resource name makes 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 usage context is implied by the description, but there is no explicit guidance on when to use this tool versus alternatives like github_list_prs. It also does not mention any prerequisites or filtering scenarios that would make this the right choice.
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. It mentions the return value ('organized tasks with priorities') but does not disclose side effects, output format details, or any limitations. This is minimal transparency for an agent to understand the tool's behavior beyond simple generation.
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 short, front-loaded sentences that state the purpose and the return value. There is no filler or redundant information, making it appropriately concise.
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 no annotations and no output schema, the description needs to provide more behavioral detail. It does not explain the 'format' parameter (markdown vs json) or the structure of the returned task list, leaving significant gaps for an agent to invoke correctly.
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 already covers 100% of the parameters with descriptions, so the baseline is 3. The description adds no additional parameter-specific meaning; it only aligns with the 'description' parameter but does not enrich understanding of 'format' or 'description' 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 what the tool does: 'Create a structured task list from a description.' It uses a specific verb and resource, and mentions the output ('Returns organized tasks with priorities'). This distinguishes it from the sibling tools, which are all GitHub/code-related.
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 by stating what it does, but does not explicitly say when to use this tool versus alternatives or provide exclusions. The sibling tools are clearly different, so differentiation is immediate, but no additional usage context is 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 the burden of disclosing behavior. Listing pull requests is implicitly read-only, and the description mentions return fields but does not explicitly state that it causes no side effects, nor does it note any rate limits or pagination behavior. The schema covers filtering and limits, but the description alone is somewhat sparse.
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 core action and then the return fields. It is well-structured and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with four parameters and no output schema, the description covers the return values adequately. The schema fills in parameter details. However, it could be improved by explicitly noting the default state filter (open) and the limit parameter, though those are in the schema, so the description is reasonably 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 description coverage is 100% (all four parameters have descriptions), so the baseline is 3. The description adds no additional parameter information beyond what the schema already provides, such as owner/repo semantics or the state enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List pull requests in a GitHub repository' with a specific verb and resource, and distinguishes it from sibling tools like github_list_issues by explicitly mentioning pull requests. It also lists the returned fields, which adds clarity.
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?
There is no guidance on when to use this tool versus alternatives such as github_list_issues. The description merely states what it does without indicating exclusions or scenarios where another tool would be preferred.
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. It only states 'Returns a detailed report,' which is minimal. It does not disclose whether the tool executes code, what kind of issues it detects, if it requires network access, or any limitations or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is neither verbose nor under-specified. It communicates the core purpose and return type with zero wasted words.
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, but there is no output schema, so the description must clarify the return value. 'Detailed report' is vague and does not convey the structure or content of the report. The schema covers parameters well, but the lack of behavioral detail and return format leaves gaps.
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 already describes both parameters (code and language) with 100% coverage. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.
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 states a specific verb ('Analyze') and resource ('code') with clear scope ('quality, complexity, and potential issues'). This clearly distinguishes analyze_code from the provided sibling tools (GitHub operations, task creation, file reads).
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 for use (when you want a code quality/complexity analysis), but it does not explicitly mention alternatives or when-not-to-use. However, the sibling tools are so different that the use case is obvious, and no exclusions are needed.
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 discloses that the tool returns text content, which adds some behavioral detail, but it does not mention error handling, permission requirements, or edge cases like binary files. The read-only nature is implied by 'Read'.
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 short sentences, front-loaded with the action, and contains no unnecessary words. It is optimally concise and well-structured.
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 covers the core purpose and the return format, which is essential because there is no output schema. It does not discuss edge cases or compare with sibling tools, but given the tool's simplicity and the schema's completeness, it is largely sufficient.
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 100%, so all four parameters are documented in the schema. The description adds no additional parameter semantics, and the baseline of 3 applies since the schema handles the parameter details.
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 'Read' and identifies the resource as 'contents of a file from a GitHub repository.' This clearly distinguishes it from siblings like github_readme (reads README specifically) and github_search_repos (searches repositories).
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 only states what the tool does without explicitly contrasting it with alternatives or providing when/when-not guidance. Usage is implied by the clear purpose, but there are no exclusions or recommendations relative to siblings like github_readme.
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 does disclose that the tool returns markdown content, which is useful. However, it does not mention behavior on missing README files, authentication requirements, or rate limits. The simple read operation partially compensates.
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 with no wasted words. It front-loads the main purpose and includes the return type, fitting within minimal length.
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 complete for a simple read tool: it states the resource and return content. While it doesn't specify default branch behavior or error handling, the simplicity and absence of an output schema make this adequate. Sibling tools are not explicitly disambiguated, but the tool's narrow scope reduces the need.
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 100% with both 'owner' and 'repo' having simple descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline of 3 is appropriate.
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 specifies the action ('Read'), the resource ('README file of a GitHub repository'), and the output ('Returns the markdown content'). It distinguishes from the sibling tool github_read_file by focusing specifically on the README file.
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 the README is needed, but it does not explicitly mention when to use this tool over github_read_file or any other alternatives. There are no exclusions or prerequisites stated.
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 the full burden of behavioral disclosure. It mentions that the tool returns repo name, description, stars, and URL, which provides some transparency about output. However, it does not explicitly state that the operation is read-only, nor disclose potential rate limits or authentication requirements, leaving some gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two short sentences that immediately state the tool's purpose and return value. Every word adds value, with no repetition or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with three parameters and no output schema, the description provides sufficient context: it explains what the tool searches, and what fields are returned. The schema covers parameter details. The lack of annotations is a minor gap, but the tool is straightforward, so the description is largely complete for an agent to select and invoke it correctly.
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 has 100% coverage, with descriptions for all three parameters (query, sort, limit). The description adds minimal extra meaning beyond restating that search can be done by keyword, language, or topic, which is already in the query parameter description. Therefore, the baseline score of 3 is appropriate.
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: 'Search GitHub repositories by keyword, language, or topic.' It specifies the resource (repositories) and the action (search), and distinguishes itself from sibling tools like github_read_file and github_list_issues, which handle different operations.
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 for when to use the tool: when searching for GitHub repositories by keyword, language, or topic. It does not explicitly name alternatives or exclusions, but no sibling tool offers search functionality, so the use case is well-defined.
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-toolkit-pro MCP server](https://glama.ai/mcp/servers/DzAchref/mcp-toolkit-pro/badges/card.svg)](https://glama.ai/mcp/servers/DzAchref/mcp-toolkit-pro)

Score Badge

Copy to your README.md:

[![mcp-toolkit-pro MCP server](https://glama.ai/mcp/servers/DzAchref/mcp-toolkit-pro/badges/score.svg)](https://glama.ai/mcp/servers/DzAchref/mcp-toolkit-pro)

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/DzAchref/mcp-toolkit-pro'

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