open-source-contribution-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with user skills tools covering separate CRUD operations (get, set, add, remove, clear) and the remaining tools targeting different workflow stages (issue discovery, repo analysis, PR tracking, code/test generation, submission, feedback). There is no meaningful overlap between any two tools, even within the skills family, as descriptions clarify the differences in behavior.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern (e.g., get_user_skills, find_issues, generate_code_fix). The verbs and nouns are descriptive and align with the action, and there is no mixing of conventions or unusual naming styles.
Tool Count5/5
With 12 tools, the server is well-scoped for its stated purpose of managing open-source contributions. Each tool covers a necessary step in the workflow, from profile management to submission and feedback, without redundancy or bloat.
Completeness4/5
The tool set covers the core workflow comprehensively: skills management, issue discovery, repository analysis, fix and test generation, PR submission, tracking, and review feedback. The main gap is the lack of a tool to update an existing PR with follow-up fixes after review feedback, leaving a potential dead end in the iterative contribution loop.
Average 3.5/5 across 12 of 12 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It states that it adds or updates skills, implying mutation, but does not explain what happens when a skill already exists (overwrite, error, merge), whether it is idempotent, or any authentication or authorization requirements. For a state-changing tool, this is insufficient.
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, clear sentence that front-loads the core action ('add'/'update') and the object ('skills'). It is appropriately sized with no unnecessary words, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a clear schema, the description covers the basic purpose but lacks important contextual distinctions from sibling tools (e.g., 'set_user_skills') and does not explain behavior boundaries like adding/updating vs. replacing. This could lead to incorrect tool selection in a larger set of skill-management tools.
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 already documents the 'skills' parameter structure, including the required 'name' and optional 'proficiency' enum with descriptions. The description's mention of 'update existing skill proficiencies' aligns with the schema but adds no new details beyond what the schema provides. With full schema coverage, the description offers only marginal extra value.
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 uses specific verbs 'add' and 'update' and identifies the resource 'user skills' with scope ('new skills or existing skill proficiencies'). It clearly conveys the tool's function, but it does not explicitly differentiate from the sibling tool 'set_user_skills,' so it is clear but not fully distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'set_user_skills' or 'remove_user_skill.' It only says 'anytime,' which is not a contextual condition. There are no exclusions, prerequisites, or alternative tool mentions.
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 carry the full burden. It states that the tool 'generates' a diff fix, implying it does not apply changes, but it does not disclose output format, side effects, authentication needs, or whether it modifies any repository. This leaves significant behavioral aspects undisclosed.
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 gets straight to the point with a clear verb and resource. It contains no filler or redundant phrases, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters, no annotations, and no output schema, the description does not explain what the tool returns, how the parameters interrelate, or any prerequisites. It is a minimal purpose statement that leaves significant contextual gaps for a tool of this complexity.
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 descriptions already cover 100% of parameters, so the baseline is 3. The description adds the qualifiers 'scoped' and 'adhering to target repo conventions', which informally relate to the 'proposedChanges' and 'targetFilePath' parameters, but it does not provide additional structural or formatting details beyond what the schema already states.
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 the tool's main action: 'Generate scoped, file-level diff fix for an issue'. It clearly identifies the resource (an issue) and the output (a diff fix), and distinguishes this from sibling tools like 'generate_unit_tests' or 'submit_pull_request' by focusing on code fixes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives. It does not mention scenarios where it should or should not be used, nor does it reference any sibling tools. The only context is the purpose itself, which is insufficient for an agent to decide between this and related tools like 'generate_unit_tests' or 'submit_pull_request'.
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 provided, the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects (e.g., writes to a file), prerequisites, permissions, or return behavior. This is a significant transparency gap for a tool that likely modifies a repository.
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 redundant words. It effectively communicates the core purpose in a minimal format, earning full marks for conciseness.
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 tool's complexity (generating and potentially writing test files) and the absence of annotations and output schema, the description is insufficient. It omits critical context such as whether the test code is written to the specified file path, how the repository is used, or what happens after execution. The schema covers parameters but not the tool's overall behavior.
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?
All four parameters are fully described in the input schema, meeting the 100% coverage threshold. The description adds no additional meaning beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and the object ('matching unit tests for the proposed code fix'), making it distinct from sibling tools like generate_code_fix. It unambiguously identifies the tool's purpose without unnecessary detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, when not to use it, or mentions any alternatives. It does not reference sibling tools or workflow order, leaving the usage context entirely 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 must disclose behavioral traits itself. It states the destructive 'Reset all' action but does not mention whether the action is reversible, requires confirmation, or what the return value is—leaving the agent without critical safety 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?
The description is a single, direct sentence that conveys the essential action without any filler. It earns a top score for clarity and brevity.
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?
The tool is destructive and has no annotations or output schema. The description covers the basic action but omits important operational details like irreversibility, side effects, or when this should be preferred over remove_user_skill, making it incomplete for safe usage.
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 no properties (0 params), so the description has no parameters to explain. Per the rubric, 0 params yields a baseline of 4; the description adds nothing but also needs to add nothing.
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 uses the specific verb 'Reset' and identifies the resource as 'all user skills and preferences', making the tool's purpose clear. It distinguishes from siblings like remove_user_skill by resetting everything at once, though it does not explicitly name alternatives.
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 'Reset all' implies that this tool is for clearing all skills/preferences as opposed to individual add/remove operations, but there is no explicit when-to-use guidance or exclusion scenarios.
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 fully disclose behavior. It mentions 'multiple sources' and 'rank' but does not specify what sources are queried, how ranking works, or whether the operation is read-only or has side effects. Given the mutation-oriented siblings, the read-only nature is not assumed.
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, tightly packed sentence that front-loads the action ('Discover and rank') and includes all necessary scope information. No filler or redundant details are present.
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 no output schema, so the description should clarify return values. It implies a ranked list of issues but lacks specifics about sources, ranking criteria, or how the saved profile is used. While the parameter surface is simple, the behavioral gaps prevent a higher score.
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 parameters (limit, overrideSkills) already well-documented. The description adds minimal semantic value beyond implying that 'user skills' default to a saved profile, and 'overrideSkills' allows replacing them. Baseline 3 is appropriate since the schema does the heavy lifting.
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 ('Discover and rank') with a clear resource ('open-source issues') and scope ('matching user skills across multiple sources'). It distinguishes from sibling tools that manage skills or handle PRs, making the tool's 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage is for finding issues based on skills, but does not mention exclusions, prerequisites, or why it should be chosen over sibling tools like analyze_repo_context or get_user_skills.
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?
There are no annotations, so the description must carry the burden. It lists possible statuses but does not disclose whether the operation is read-only, whether it makes any changes, or any side effects. The behavioral traits are left implicit.
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. Every part adds value by naming the action and the possible statuses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the core purpose and possible statuses. However, it does not explain the return format, whether it polls/waits, or any prerequisites, leaving some gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described in the input schema. The description adds no additional parameter-specific meaning beyond what the schema already provides.
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's function: tracking PR statuses such as open, changes requested, approved, merged, and closed. This is specific and distinguishes it from sibling tools like submit_pull_request or find_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 is provided on when to use this tool versus alternatives like get_review_feedback or find_issues. The tool name and parameters imply tracking a specific PR, but usage context is not explicitly described.
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 responsibility for behavioral disclosure. It only says 'Set or overwrite' and does not clarify whether omitted fields (avoidTags, scopePreferences) are cleared, whether it merges with existing skills or fully replaces them, or any side effects. This ambiguity is significant for a mutation 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?
A single sentence with the action verb and resource front-loaded. No filler words, and it conveys the core operation efficiently.
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?
For a tool with no annotations and no output schema, this description is too sparse. It fails to explain overwrite semantics (full replacement vs. merge), the fate of optional fields, or the expected result. In the context of sibling skill-management tools, this is insufficient for correct selection and invocation.
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 provides 100% coverage for all three parameters with descriptions and enum values. The description adds little beyond naming 'scope preferences', but the baseline of 3 applies because the schema already documents parameters effectively.
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 phrase 'Set or overwrite' and names the resource 'user skill tags and scope preferences'. This clearly differentiates from sibling tools like add_user_skills (additive) and clear_user_skills (removal) by implying replacement semantics.
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 word 'overwrite' implies this should be used when replacing existing skill tags, but the description does not explicitly state when to prefer this over add_user_skills or remove_user_skill. It provides implied usage context without explicit alternatives or exclusions.
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. It reveals that the tool performs read operations on specific sources, but it does not disclose return format, error handling, or any potential side effects. The term 'Mandatory' hints at a behavioral gate but lacks clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently lists what is read. The word 'Mandatory' is slightly vague but does not add unnecessary length.
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?
The tool has no output schema and no annotations, so the description must explain the result or effect. It only says 'reads' without indicating what is returned or why it is mandatory. This leaves the agent uncertain about the tool's outcome.
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 a complete description for the 'repo' parameter, including format and example. The tool description adds no parameter-specific meaning, so the baseline of 3 is appropriate given 100% 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?
The description states a specific action: reads four types of repo context. This clearly distinguishes it from sibling tools like get_user_skills, find_issues, and generate_code_fix.
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 word 'Mandatory' implies the tool is a required prerequisite, but the description does not explicitly state when to use it versus alternatives or when not to use it. It provides only vague implication of required usage.
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 full burden. It discloses that the tool fetches comments and generates instructions, but does not state whether it is read-only, whether it modifies anything, requires permissions, or what the response format looks like. This is a significant gap for a tool that may have 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 states the verb and resource immediately. It contains no filler and every word contributes to the meaning.
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 with two well-documented parameters, but there is no output schema. The description says it generates instructions but does not describe the output format, pagination, or any error behavior. It is adequate for basic understanding but leaves some 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?
Schema description coverage is 100% – both 'repo' and 'prNumber' have clear descriptions. The tool description adds no extra semantic context beyond what the schema already provides, so the baseline 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 uses specific verbs 'Fetch' and 'generate' with a clear resource ('maintainer review comments for a PR') and scope ('follow-up fix instructions'). This distinguishes it from sibling tools like generate_code_fix and find_issues, which target related but 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('when you need maintainer review comments and fix instructions') but provides no explicit guidance on alternatives or exclusions. It does not mention, for example, using generate_code_fix for direct code fixes, leaving the agent to infer the 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?
No annotations are provided, so the description carries the full behavioral burden. It states that it removes a skill but does not disclose what happens if the skill does not exist, whether the operation is idempotent, or whether any permissions are required. Given it's a mutating operation, the lack of side-effect disclosure is a notable 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, succinct sentence with no filler words. It efficiently conveys the action and object. For such a simple tool with one parameter, this level of brevity is appropriate and every word contributes meaning.
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 a very low complexity (one parameter, no output schema), so the description is arguably sufficient for a basic understanding. However, without annotations or additional behavioral context, the description leaves gaps about error handling and post-conditions. It is adequate for a simple operation but not fully complete in terms of user guidance.
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 provides 100% coverage, with the parameter 'skillName' described as 'Name of the skill to remove', which aligns with the description. The description does not add further nuance beyond the schema, so a baseline score of 3 is appropriate. The parameter is straightforward and well-documented.
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 a specific verb ('Remove') and resource ('specific skill tag') from the 'active profile', which directly differentiates it from sibling tools like add_user_skills, set_user_skills, and clear_user_skills. It explicitly indicates the scope ('specific' rather than all skills), leaving no ambiguity about its function.
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 only through the verb and object, but does not explicitly contrast with alternatives. For example, it does not state when to use this tool instead of clear_user_skills or set_user_skills, nor does it mention any prerequisites or context. The sibling list and tool name suggest the use case, but the description alone offers no explicit 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 of disclosing behavioral traits. It explicitly states the confirmation gate ('Only runs when confirmed is set to true by human approval'), which is a key safety and execution behavior. It does not detail side effects like repository changes or permissions, but the most critical gating behavior is transparently disclosed.
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 states the purpose and the critical behavioral condition without any fluff. Every word adds value, making it an exemplary concise description.
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 (9 required params), the description plus full schema coverage is sufficient for an agent to invoke it correctly. It discloses the unique confirmation requirement, and while it doesn't describe return values or prerequisites, the absence of an output schema and the clear schema documentation keep this within a well-rounded description.
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 100%, so all parameters are already documented with descriptions. The description reinforces the 'confirmed' parameter's importance, but adds no further semantic detail beyond what the schema provides. This meets the baseline for schema-heavy tools.
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 ('Submit') and resource ('pull request to target repository'), and clearly distinguishes itself from sibling tools by focusing on PR submission, not user skills or code generation. The 'approved' and 'confirmed' conditions further specify the exact action and precondition.
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 by stating the tool only executes when human approval is confirmed, establishing when it is appropriate to invoke. It does not explicitly name alternative tools, but the context signals and sibling names make it clear this is for the final PR submission step, not for generating fixes or reviewing code.
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?
Annotations are absent, so the description carries the full burden. 'Get' implies a read operation with no side effects, but it does not disclose return format, authorization needs, or any other behavioral nuances. For a simple getter, it is adequate but not rich.
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 states the purpose and the data returned. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is fully sufficient—it explains what the tool returns (skills, proficiency levels, scope preferences) and clearly labels it as a retrieval operation.
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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meaning, and the input schema confirms no 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 uses the specific verb 'Get' with a clear resource ('currently registered skills, proficiency levels, and scope preferences'), distinguishing it from sibling mutation tools like set_user_skills, add_user_skills, remove_user_skill, and clear_user_skills.
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 term 'Get' clearly implies read-only usage, which is distinct from the modifying siblings. However, there is no explicit 'when to use vs alternatives' guidance, but the context is clear because all sibling tools are mutations or unrelated tasks.
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

open-source-contribution-mcp-server MCP server

Copy to your README.md:

[![open-source-contribution-mcp-server MCP server](https://glama.ai/mcp/servers/devkamani9313-lab/open-source-contribution-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/devkamani9313-lab/open-source-contribution-mcp-server)

Score Badge

Copy to your README.md:

[![open-source-contribution-mcp-server MCP server](https://glama.ai/mcp/servers/devkamani9313-lab/open-source-contribution-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/devkamani9313-lab/open-source-contribution-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/devkamani9313-lab/open-source-contribution-mcp-server'

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