coding-agent-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool addresses a distinct resource or action: agent discovery, repository discovery, task lifecycle management, output retrieval, git inspection, and verification. There is no meaningful overlap between get_task and get_task_output, or between get_repo_status and get_diff.
Naming Consistency5/5All tools follow a consistent snake_case verb_noun pattern (list_*, start_*, cancel_*, continue_*, get_*, run_*). The naming is predictable and makes the action-resource relationship clear across the entire set.
Tool Count5/5Ten tools is well-scoped for a coding-agent orchestration server. Each tool covers a necessary operation without redundancy, and the count is within the ideal range for maintainability and agent usability.
Completeness5/5The tool surface covers the full task lifecycle: create (start_task), read (get_task, get_task_output), update (continue_task), and cancel (cancel_task). It also provides discovery (list_agents, list_repositories), repository inspection (get_repo_status, get_diff), and verification (run_verification), leaving no obvious dead ends for the stated purpose.
Average 3.4/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.jsonto 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 of behavioral disclosure. It indicates a read-only retrieval operation, but does not mention possible states, error behavior, permissions, or what 'concise metadata' includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It front-loads the action and result, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with full schema coverage, the description is minimally viable. However, the absence of an output schema and any behavioral details leaves gaps about what state values exist and how the response is structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description clearly states that task_id is the task identifier to query. The description adds no extra semantic detail, which is acceptable given the schema already covers the single parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and names the resource ('task state and concise metadata'), making the tool's basic purpose clear. It is distinguishable from the sibling get_task_output, which presumably returns full output, though this distinction is not stated explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like get_task_output, start_task, or cancel_task. The intended context is only implied by the tool name and description rather than stated.
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 says the profile 'runs' but does not disclose whether execution is synchronous, whether it produces artifacts or side effects, whether a task must be active, or how results are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, readable sentence that front-loads the action and includes helpful examples. It is appropriately concise, though it omits behavioral details that would make it more complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain how verification output is obtained and whether the run is asynchronous or blocking. It does neither, leaving an agent uncertain about what happens after the command is invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds minor value with profile examples and the workspace/repository context, but it does not clarify the relationship between task_id and repository beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Runs') on a specific resource ('configured verification profile') and gives concrete examples such as test and lint. It is clearly distinguishable from siblings like start_task or get_repo_status, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples 'e.g. test, lint' and the mention of 'task workspace or repository' give useful context for when to invoke the tool. However, it does not explain when to prefer task_id versus repository, nor does it point to alternatives like get_task_output for retrieving results.
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, but it only states that a task starts. It does not say whether the task runs asynchronously, whether a task ID is returned, what side effects occur in the workspace, or how the result can be obtained afterward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no filler. Since the input schema already documents all parameters and enums, keeping the description short is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that starts an external coding-agent task and has no output schema or annotations, the description is incomplete. It omits critical context such as return behavior, async execution, how to reference the started task later, and the need for repository/agent aliases to be configured beforehand.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning beyond what the schema already provides; it only loosely echoes the 'repository workspace' concept without clarifying alias configuration or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Starts') and a concrete resource ('coding-agent task in a configured repository workspace'). This clearly distinguishes it from sibling tools like cancel_task, continue_task, get_task, and get_diff, since 'start' signals a new task rather than a status or follow-up operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites such as listing agents/repositories first, nor does it clarify that this tool is for new tasks while continue_task is for resuming existing ones. The agent is left to infer usage purely from the verb 'Starts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. The description states the action but does not reveal whether cancellation is irreversible, what happens to in-progress work, what status change results, or whether cancellation is synchronous. For a destructive mutation, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word earns its place, and the size is appropriate for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally sufficient: it tells the agent what to pass (task_id) and what the effect is (cancel running task). However, it omits return behavior, error conditions, and side effects, and there is no output schema to compensate, leaving some ambiguity for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with task_id already described as 'Task ID to cancel.' The description adds no additional meaning beyond what the input schema already provides, so the baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('Cancels') with a clear resource ('coding-agent task') and adds the qualifier 'running' to limit scope. This distinguishes it from sibling tools like start_task, continue_task, and get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'running' implies it should be used for tasks that are currently active, but no explicit when-to-use or alternative guidance is provided. It does not mention behaviors for completed tasks or point to any sibling tool as a better fit in other cases.
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 restates the core action without explaining consequences such as whether the task must still be active, whether the follow-up triggers execution, or what happens if the session is already completed/canceled. The description adds little beyond what the tool name and schema already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler, redundant phrasing, or irrelevant detail. It is front-loaded with the key verb and object, making it immediately scannable by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two self-documented parameters, so a short description is acceptable. However, with no output schema or annotations, the description does not cover what the agent should expect after sending the instruction or whether there are task-state prerequisites. It is minimally viable but not fully complete for safe invocation in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both task_id and instruction adequately. The description does not add extra meaning about formats, constraints, or relationships between the parameters, but it is consistent with the schema's meaning. This meets the baseline for fully documented schema parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('sends') and a specific resource ('follow-up instructions to an existing task session'), clearly distinguishing it from siblings like start_task, cancel_task, and get_task. The word 'existing' and 'follow-up' make the tool's role obvious without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for continuing an already-created task session, which gives some usage context. However, it does not explicitly state when not to use it or mention alternatives such as start_task for new tasks or get_task/get_task_output for checking state. Usage guidance is inferred rather than explicit.
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 behavioral burden. 'Returns structured Git status' implies a read-only operation and hints at the return shape, but it does not disclose edge-case behavior, failure modes, or what happens when both/neither parameter is supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. The key information—what is returned and for what targets—is front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two optional params, no output schema), and the description covers the core purpose. However, it omits behavior when no parameter is provided or both are provided, and does not orient the agent relative to the sibling diff/list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds little beyond the schema, only reaffirming that the status applies to either a task workspace or a repository root. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), resource ('structured Git status'), and scope ('task workspace or configured repository'), making the tool's function clear. It does not explicitly differentiate from siblings like get_diff, but the name and object are sufficiently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about the two target modes (task workspace vs configured repository), which is implied by the parameters. However, it gives no explicit guidance on when to prefer this tool over siblings like get_diff, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The word 'Returns' indicates a read-only operation and 'safe metadata' suggests no side effects. However, it does not explain what 'safe metadata' includes, whether the result set is sorted, or what happens if no repositories are configured. Basic transparency is present but shallow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler. The key verb 'Returns' is front-loaded, and the object of the return is specified. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema listing tool, the description covers the essential purpose. It could be more explicit about the return format and the meaning of 'safe metadata', but the tool is simple enough that an agent can call it confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden for the description to carry. The baseline of 4 applies because no parameter documentation is needed; the description is sufficient for calling the tool with an empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the verb ('Returns') and the resource ('configured repository aliases and safe metadata'), which distinguishes it from sibling tools like list_agents and get_repo_status. The phrase 'safe metadata' is slightly vague, but the core purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention prerequisites, when it should be preferred over list_agents or get_repo_status, or any exclusions. The usage context is left entirely to inference.
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 should disclose behavior. It indicates this is a read-only listing operation and mentions 'local availability', which is a useful behavioral trait. However, it does not explain what 'availability' means in practice (e.g., statuses, offline agents, error conditions), leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose and an additional qualifier ('local availability') with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description is sufficient to understand what it returns. However, the lack of output schema and absence of details about the return structure or meaning of 'availability' means the agent may not know what data fields to expect. Still, this is a simple tool and the description covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema carries no semantic burden. The description does not need to explain parameters, and the absence of parameter documentation is not a gap. Baseline 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Returns') and resource ('configured coding agents') and adds the scope 'local availability', which differentiates it from sibling tools like list_repositories. It is specific enough to be understood, though it does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: retrieving available coding agents. It does not state when to prefer this over list_repositories or other sibling tools, but given the tool name and description, the intended context is reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does add useful context by stating the diff includes committed changes since the task base SHA and untracked files. However, it does not mention that the operation is read-only, how max_bytes truncation behaves, or what happens if both task_id and repository are supplied. These are meaningful behavioral gaps 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the primary action and resource, then adds the key scoping detail about committed changes and untracked files. There is no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the high-level purpose and diff scope well, and the schema documents all parameters. However, there is no output schema and no annotations, so the agent is left without explicit guidance on return format, truncation behavior, error cases, or interaction between task_id and repository. This is adequate but not fully complete for a tool with four optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a little value by clarifying that the diff can come from a task workspace or a configured repository, which maps to task_id and repository. It does not elaborate on staged or max_bytes beyond what the schema already provides, which is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a Git diff for either a task workspace or a configured repository, and it specifies the diff scope (committed changes since task base SHA and untracked files). This is specific enough to distinguish it from siblings like get_repo_status, which presumably returns status rather than diff content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need the actual Git diff for a workspace or repository. However, it does not explicitly contrast it with get_repo_status or other siblings, nor does it explain when one should prefer this over alternatives. The 'or configured repository' phrasing hints at mutually exclusive modes but does not explicitly state precedence or conflict behavior.
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?
Because no annotations are provided, the description carries the full burden of behavioral disclosure. It does add transparency by stating that output is bounded and paginated, which signals truncation and the need for cursor-based iteration. However, it omits edge-case behavior such as invalid cursors, empty output, task completion requirements, or whether the call is safe/read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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 return action, the resource, the output bound, and the pagination capability in order of importance, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter read tool, the description plus schema covers the basic call shape, but the absence of an output schema and any mention of the response format leaves a gap. In particular, the agent is not told how the cursor is obtained or used across pages, which is essential for effectively consuming a paginated result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already explains cursor as a byte offset and max_bytes as a byte limit. The description's 'pagination cursor support' adds contextual meaning but no additional syntax or format details, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), a concrete resource ('task output'), and crucial qualifiers ('bounded', 'pagination cursor support') that immediately distinguish this tool from sibling get_task and the other agent-management tools. Even without opening the schema, an agent can understand what this tool does and how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case—fetching potentially large task output in bounded chunks using a pagination cursor—but it never explicitly says when to choose this over get_task or other siblings. No alternatives or when-not-to-use conditions are mentioned, so the agent must infer the routing decision.
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:
Score Badge
Copy to your README.md: