@voxos-ai/clink-mcp-server

Official

by Voxos-ai-Inc

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.4.1
Disambiguation4/5
Most tools clearly target distinct resources (proposals, clinks, milestones, projects, permissions) with action-specific verbs, making selection straightforward. The only notable overlap is between get_clinks and check_inbox, both retrieving clinks but with different intents (filtered search vs. inbox check). Overall, the risk of misselection is low.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (list_, get_, create_, update_, complete_, etc.). Verbs are action-specific and nouns identify the resource, creating a highly predictable and uniform naming convention. There are no mixed styles or vague verbs.
Tool Count2/5
With 32 tools, the server significantly exceeds the threshold for 'too many' (25+). While the breadth reflects a comprehensive collaboration platform, this quantity is overwhelming and likely to increase agent confusion and selection cost. The tool set could be split into focused servers or consolidated to reduce redundancy.
Completeness4/5
The tool set covers the full lifecycle for projects, milestones (including checkpoints), and proposals, with create/read/update/complete/archive/reopen operations. However, there are no delete operations for any major entity, and proposals and clinks lack update functionality. These gaps are minor and can be worked around via completion or archival, so agents are unlikely to hit dead ends.
Average 3.9/5 across 32 of 32 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 25, 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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions 'shows status and milestone organization' but does not explicitly state read-only behavior, ordering, pagination, or error handling. Since 'list' implies a read operation, some behavior is inferred, but the description lacks detailed 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 only two short sentences, with the core purpose front-loaded and no extraneous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with three parameters and no output schema, the description is minimally adequate. It states the purpose and vague output hints, but given no annotations or output schema, more detail on response structure or default behavior would improve completeness.
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 parameter schema has 100% description coverage, so the baseline is 3. The description does not add extra meaning to the parameters beyond what the schema already provides; 'shows status' is a vague output hint rather than param-specific semantics.
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 lists projects for a Clink group, with a specific verb and resource. It also adds output context about status and milestone organization, which distinguishes it from sibling tools like list_proposals and get_project.
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. It does not mention exclusions or reference sibling tools like list_groups or get_project, leaving the agent without explicit selection criteria.
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 fails to mention that voting is a write operation, whether it is reversible, any permission requirements, or the presence of a verification email (hinted by hil_expiry_seconds). This is a significant gap for a mutation tool, leaving the agent unaware of 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 two sentences, front-loaded with the primary action, and contains no filler. Every sentence contributes useful guidance, making it highly efficient and well-structured.
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 annotations and no output schema, but includes a non-obvious hil_expiry_seconds parameter hinting at email verification. The description does not explain this verification flow, possible outcomes, error scenarios, or what happens after voting. This leaves the description incomplete for a mutation tool of moderate 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?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds some emphasis on vote format for yes/no and single choice, but omits ranked voting and hil_expiry_seconds entirely. This does not add substantial meaning beyond the schema, meriting the baseline score of 3.
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 action: 'Cast a vote on a proposal.' This specific verb+resource framing distinguishes it from sibling tools like create_proposal, finalize_proposal, or list_proposals, making the purpose immediately obvious.
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 defining the tool as the voting action, but it does not explicitly state when to choose this tool over alternatives or provide exclusions. It does give format guidance for yes/no and single-choice votes, which is helpful but not full tool-selection guidance.
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 full responsibility for behavioral disclosure, but it only states the action and supported options. It does not mention whether the proposal is immediately open for voting, whether it can be edited or withdrawn, what permissions are required, or what the response contains — significant gaps for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences that front-load the core purpose and then briefly expand on key features. Every word earns its place and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 7 parameters and no output schema, the description plus detailed schema is adequate but not complete. It lacks guidance on side effects, return values, or operational context like whether a proposal can be iterated. The tool is straightforward enough to be usable, but gaps remain.
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 the schema already explains every parameter. The description adds minimal semantic value beyond restating that voting types and thresholds are supported, which is already captured in the schema's enum descriptions. Thus the 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 states a specific verb ('Create') and resource ('voting proposal') with context ('for group decision-making'), immediately distinguishing it from sibling tools like list_proposals, get_proposal, and cast_vote. It also previews key configurable aspects (voting types and thresholds), making the tool's purpose unmistakable.
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 creating a proposal) but does not explicitly contrast it with alternatives or state when not to use it. It mentions supported voting types and thresholds but gives no guidance on choosing between them or any prerequisites like group membership or permissions.
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 must convey behavior. It implies a read-only operation via 'Get' and specifies the returned data (checkpoints and their status), but it does not mention permissions, errors, or side effects. This 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, clear sentence with no redundancy. It is front-loaded with the main action and follows with a concise detail about the response.
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 simple profile (one parameter, no output schema), the description provides a good overview of the return content. It highlights checkpoints and their status, which is key context, though it could mention whether all milestone fields are included.
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 fully documents the sole parameter milestone_id with a clear description. The tool 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 tool retrieves detailed information about a specific milestone, including checkpoints and their status. This distinguishes it from list_milestones, which likely returns a list rather than deep 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 explicit guidance on when to use this tool versus alternatives like list_milestones. It only states the function without mentioning any context or exclusions, leaving the agent to infer usage from the verb 'get'.
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 disclosing behavioral effects. It mentions the completion action and optional reply, but doesn't state side effects like whether the claim is removed, whether the reply becomes a new clink, or if completion is reversible. This is a mutation tool, so more disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the primary action, and every sentence adds value. The prerequisite and optional reply are stated clearly with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the core purpose and prerequisite. However, it lacks critical behavioral details such as what happens after completion (e.g., does the clink become read-only?) and whether the optional reply is sent as a new clink. Given no output schema and no annotations, a bit more context would improve completeness.
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% for both parameters, so the baseline is 3. The description adds context for the 'response' parameter by explaining it as a reply to the original sender, which is consistent with the schema description. The 'clink_id' parameter is already self-documented in 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 uses a specific verb ('Mark') and resource ('a claimed clink as completed'), clearly distinguishing it from sibling tools like claim_clink and release_clink. It also mentions the optional reply, which differentiates it further from send_clink.
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 states a clear prerequisite: 'You must have claimed the clink first.' This implies usage context and that claim_clink should be used before this tool. It doesn't explicitly name alternatives, but the condition is actionable and clear.
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 discloses the consensus feature, but does not mention permissions, irreversibility, return value, or side effects. The schema covers the structure, but behavioral transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and key qualifiers (checkpoints, consensus). No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 5 parameters and a nested checkpoint structure. The description covers purpose well but lacks details on return values, permissions, or constraints. With no output schema or annotations, it is slightly thin but the schema fills structural 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%, so all parameters are already documented. The description adds no extra parameter semantics beyond what the schema provides, so the baseline 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 uses a specific verb ('Create') and resource ('milestone') with additional context about checkpoints and consensus. It clearly distinguishes from siblings by focusing on creation and tracking multi-step collaborative tasks.
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?
Provides clear context ('to track multi-step collaborative tasks') implying when to use it, but does not explicitly mention alternatives or exclusions. It is understood as the tool for creating milestones with checkpoints, but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions that the result depends on threshold types, but it does not state whether closing is irreversible, what happens to the proposal's status, or whether further votes are rejected. This is a significant gap for a consequential finalizing action.
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 that immediately state the action and outcome. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, the description covers the core purpose and threshold dependency. However, it omits important contextual details such as side effects (e.g., proposal becoming immutable, votes no longer accepted) and whether the final result is returned. This is a moderate gap.
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 the schema fully documents both parameters. The description adds no parameter-specific detail beyond what is already in the schema, but it does not need to compensate; the 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 uses a specific verb ('Close voting') and resource ('a proposal'), clearly distinguishing it from siblings like cast_vote and create_proposal. It also states the outcome ('compute the final result'), which fully conveys the tool's purpose.
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 clearly implies when to use this tool: when voting on a proposal needs to be closed and a final result computed. It doesn't explicitly mention exclusions or alternatives, but the context is clear enough given the sibling tools.
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 must disclose behavioral traits. It mentions filtering by group, time range, and limit, but fails to disclose that mark_read can mutate read status, a significant side effect. It also omits details about return format or ordering, leaving the agent without full behavioral awareness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose. The second sentence provides a useful alternative pointer. No waste.
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?
With 5 parameters (including a mutating flag) and no output schema, the description is relatively brief. It covers filters but omits side effects, return structure, and edge-case behavior (e.g., mark_read with unread_only). More detail would improve completeness.
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?
Input schema covers all 5 parameters with detailed descriptions (100% coverage). The description summarizes group, time range, and limit filters but adds no new syntax or format details. 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 the verb 'Get' with the resource 'clinks from Clink groups', clearly indicating a retrieval operation. It distinguishes itself from sibling tools like send_clink, claim_clink, and check_inbox by highlighting filtering capabilities and pointing to check_inbox as an alternative for quick unread checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to check_inbox for quick unread checks, implying get_clinks is for more detailed, filtered retrieval. It does not enumerate other alternatives but provides clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the result includes milestones, which adds behavioral context, but it does not disclose potential authorization requirements, error behavior, or output format. It states a read action with no 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, clear sentence with no filler. It conveys the core purpose and the important detail about milestones without unnecessary 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?
Given the low complexity (one simple parameter) and no output schema, the description is adequate but lacks usage guidance, return shape details, or any caveats. 'Detailed information' is vague, and the milestone mention is the only concrete behavioral detail.
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 the parameter 'project_id' is already described as 'The project ID'. The description adds no extra meaning or usage details for the parameter, so 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 uses a specific verb 'Get' with a clear resource ('project') and adds that it includes milestones, distinguishing it from list_projects and get_milestone. It states exactly what information is returned.
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 detailed project data is needed, but it does not explicitly state when to use this over list_projects or get_milestone. No explicit alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing behavioral traits. It does not explicitly state that the operation is read-only or that it does not require special permissions. The word 'List' hints at non-mutating behavior, but the description omits important details such as pagination behavior, rate limits, or any prerequisites, leaving the safety profile underspecified.
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 core purpose. It avoids redundancy, and every word contributes to the tool's function. This is exemplary conciseness, with no filler or unnecessary detail.
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 list tool with well-documented parameters, the description provides the essential purpose and a hint of output content. However, with no output schema, it does not fully specify what fields are returned (e.g., proposal IDs, titles), which could be crucial for follow-up actions like get_proposal. It also lacks behavioral transparency, making the overall context only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters with 100% coverage, so the schema carries the documentation burden. The description does not add parameter-specific semantics beyond mentioning 'status and vote counts' in the output, which is not directly about the parameters. A baseline of 3 is appropriate because the schema fully documents parameters, and the description adds no conflicting or extra parameter meaning.
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 as listing voting proposals for a Clink group, using the specific verb 'List' and naming the resource. It distinguishes from siblings like get_proposal (single proposal) and cast_vote (voting action), and the additional detail about showing status and vote counts reinforces its read-only listing purpose.
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: use this tool to list proposals for a group. While it doesn't explicitly exclude alternatives or name them, the purpose is unambiguous. The presence of sibling tools like get_proposal could benefit from an explicit contrast, but the core usage is evident from the verb and resource.
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 behavioral disclosure burden. It only lists updatable fields and does not mention side effects like dependency cycle validation, permission requirements, or that updating overwrites existing values. This is a significant gap 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?
The entire description is one focused sentence, front-loading the verb and resource and avoiding any 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 has 8 parameters and no annotations or output schema. The description gives a useful overview but lacks behavioral context such as validation rules (though these partially appear in the schema). For a mutation tool, a bit more context would be needed to make it self-contained.
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 documents all 8 parameters with 100% coverage, so the description adds only minimal grouping (e.g., 'git references' covers three URL params). The baseline is 3, and the description doesn't significantly enhance parameter understanding 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 uses a specific verb ('Update') and identifies the resource ('checkpoint') plus the specific fields (title, description, dependencies, git refs), clearly distinguishing it from sibling tools like add_checkpoint, complete_checkpoint, and delete_checkpoint.
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?
While the description clearly indicates this tool updates existing checkpoints, it does not provide explicit guidance on when to choose it over alternatives (e.g., add_checkpoint) or mention any preconditions. The context of sibling tool names helps, but the description itself lacks explicit exclusions or alternative references.
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 explaining behavior. It lists which fields are updated, but does not disclose whether it performs a partial update (only provided fields changed), whether it requires special permissions, what happens on invalid input, or what the return value is. This is a significant transparency gap 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?
The description is a single, front-loaded sentence that explicitly states the action and affected fields. Every word contributes to understanding; there is no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with five parameters (all optional except project_id) and no output schema or annotations, the description is minimally viable. It tells the agent what fields can be updated, but does not clarify the partial-update semantics (e.g., only provided fields change) or what the response will look like. These gaps are not critical but could confuse an agent attempting to invoke the tool 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?
Schema description coverage is 100%, so the input schema already documents each parameter. The tool description adds no additional meaning beyond naming the fields. Baseline 3 is appropriate because the schema does the heavy lifting and no extra semantic context is needed.
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 ('Update'), identifies the resource ('a project'), and enumerates the exact fields affected (title, description, slug, color). This clearly distinguishes it from sibling tools like create_project, archive_project, or reopen_project.
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: use this tool to modify the listed project fields. It does not explicitly name alternatives or exclusions, but the verb 'update' alongside the specific fields implies when it should be used versus create/archive/reopen. No misleading guidance is present.
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 disclosure burden. It reveals one behavioral trait: if no position is given, the checkpoint is appended at the end. However, it omits other important behavioral details such as permissions required, side effects on the milestone, or whether the operation is reversible. For a mutation tool, this is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and includes the key optional behavior. Every word earns its place, with no redundancy or excess detail.
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 9 parameters and no annotations or output schema, the description is only one sentence. It fails to mention prerequisites (e.g., milestone existence or permission requirements), return values, or edge cases around the complex dependencies parameter. The tool is non-trivial, and the description is too minimal to be fully 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%, so the baseline is 3. The description adds a small clarification that the milestone must already exist ('existing milestone'), but it mostly repeats the position parameter's schema description (if not provided, appends at end). It does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a new checkpoint to an existing milestone.' This uses a specific verb ('add') and resource ('checkpoint') with a clear target ('existing milestone'), distinguishing it from sibling tools like create_milestone, update_checkpoint, or delete_checkpoint.
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 noting the checkpoint is added to an existing milestone and that position is optional (appended if not specified). It implies the tool is used for inserting new checkpoints into a milestone, but it does not explicitly mention alternatives or exclusions (e.g., 'use update_checkpoint to modify an existing checkpoint').
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 explains that only pending verifications are listed and that the results show checkpoints and votes, which adds useful context. However, it does not mention read-only nature, pagination behavior, ordering, or potential permissions needed, leaving some 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 two sentences long, front-loads the main purpose, and includes no filler or redundant information. Every word contributes to understanding the tool's function and scope.
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 list tool with two parameters and no output schema, the description is largely complete. It explains the purpose, the group scope, and the expected content ('checkpoints and votes'). While it could mention the limit parameter or default behavior, those are already in the schema, and the absence of an output schema is mitigated by the clear statement of what is shown.
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% description coverage for both parameters (group and limit), so the schema already documents them fully. The description adds no additional meaning beyond the schema, which matches the baseline of 3 when 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 ('List') and resource ('pending Human-in-the-Loop verifications') with a clear scope ('for a group'). It also distinguishes itself from sibling tools by naming 'verifications' rather than proposals or votes, and clarifies it shows 'checkpoints and votes awaiting human approval.'
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 (to see pending verifications for a group) but does not explicitly state alternatives or exclusion criteria. It does not mention cases where another tool like 'list_proposals' or 'cast_vote' would be more appropriate, leaving usage context implied rather than fully guided.
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. It discloses a key behavioral constraint (cannot modify closed milestones), which is helpful for a mutation tool. However, it does not mention permissions, reversibility, or what happens when trying to update a closed milestone, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose and adds the key constraint. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with fully documented parameters and no output schema, the description is adequate. It covers the primary action, the scope (title/description), and a critical limitation (closed milestones). It could arguably mention error behavior, but nothing essential is missing.
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 the baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides for milestone_id, title, and description. It is essentially redundant with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update a milestone's title or description.' This is a specific verb-action on a resource, and the additional constraint 'Cannot modify closed milestones' differentiates it from other milestone-related tools like create_milestone or reopen_milestone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating milestone fields but does not explicitly name alternatives or describe when to choose this over sibling tools like reopen_milestone. The closed-milestone restriction provides a clear exclusion but no positive guidance.
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 transparency burden. It discloses a key behavioral constraint (consensus approval gating) but omits the HIL (human-in-the-loop) verification behavior hinted by the hil_expiry_seconds parameter, and it does not describe side effects, reversibility, or response behavior.
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 extremely concise—a single sentence with a conditional clause—and every phrase contributes meaningful guidance. It is front-loaded with the primary action and then adds a critical condition.
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?
Although the tool is relatively simple and the schema covers parameter semantics, the description misses important behavioral context about HIL verification and post-completion effects. It mentions consensus approval but does not tie it to the hil_expiry_seconds parameter or explain the verification email flow, leaving the agent to infer those details from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all three parameters (milestone_id, order, hil_expiry_seconds) well-described in the input schema. The description adds no parameter-specific details beyond what the schema already provides, so the baseline 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 clearly states the tool's function ('Mark a milestone checkpoint as completed') and adds a relevant condition about consensus approval. This distinguishes it from sibling tools like update_checkpoint and complete_project, which address different actions on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when completion is allowed: it cannot be completed until the proposal passes if consensus approval is required. This serves as an implicit when-not, but it does not explicitly name alternative tools or other usage exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It says 'Get' which implies read-only, but it does not explicitly state safety, permission needs, potential errors, or that no data is modified. This lacks the behavioral depth expected without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb, and contains no wasted words. It efficiently conveys the tool's core purpose and return content.
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?
For a simple one-parameter read tool, the description adequately explains the return value ('detailed information... including all votes and their comments'), which is sufficient given no output schema exists. It covers what the agent needs to know to invoke and interpret results.
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 covers 100% of parameters with a clear description for proposal_id ('The proposal ID'), so the baseline of 3 applies. The tool description adds no additional parameter meaning or usage 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 clearly states the verb 'Get' and the resource 'proposal', and specifies the scope 'including all votes and their comments'. This distinguishes it from siblings like list_proposals, cast_vote, and finalize_proposal.
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 that this tool is for retrieving detailed proposal data with votes and comments, implying use when such detail is needed. However, it does not explicitly state exclusions or mention alternative tools like list_proposals.
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 states that completed projects remain visible and indicate completion, which is useful. However, it does not disclose whether the action is reversible, if it locks any fields, or what happens to associated tasks/milestones. The most critical side effect (visibility) is covered, but other behaviors are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and object, followed by a concise clarifying clause. Every word serves a purpose with no redundancy, making it highly efficient.
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 tool with one required parameter and no output schema, the description adequately explains the action and its primary outcome (visibility). The only missing context is mention of the tool's reversibility via reopen_project, but this is minor given the simplicity of the operation.
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 fully documents project_id with description 'The project ID', leading to 100% schema description coverage. The description itself adds no additional parameter meaning, which aligns with the baseline expectation when schema is sufficient.
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 uses specific verb 'Mark' and resource 'a project', clearly indicating the action is to set completion state. It also adds contextual detail that completed projects remain visible, distinguishing this from archive_project which likely hides projects. This is a clear, non-tautological purpose.
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 implies when to use the tool (when all work is done) and clarifies that completed projects stay visible. However, it does not explicitly mention alternatives or exclusions, such as using update_project for partial changes or reopen_project to reverse completion. Context is present but not exhaustive.
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 disclosing behavior. It mentions the uniqueness of slugs within a group, which is a useful behavioral detail. However, it does not disclose permissions, return values, side effects, or error cases, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no redundant filler. Every sentence earns its place, providing purpose and a useful constraint.
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 provides sufficient context for a create-project tool with a well-documented schema. It lacks return value and permission details, but given no output schema and the tool's simplicity, these are not critical. Slightly incomplete but acceptable.
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, documenting all five parameters with descriptions. The description adds a small note about slug uniqueness but otherwise relies on the schema. Baseline 3 is appropriate given the high 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 clearly states the action ('Create a new project') and the resource ('in a Clink group'), adding context that projects organize milestones. This distinguishes it from sibling tools like create_proposal and create_milestone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this tool is for creating projects and notes the unique slug constraint within a group. It does not explicitly name alternatives or exclusions, but the context is sufficient to differentiate from other creation tools.
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 must carry the behavioral disclosure burden. The description reveals a key constraint (cannot delete completed/dependent checkpoints) but does not specify what happens on violation (error vs no-op), permissions, or reversibility, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: it states the core action and the key restriction. It is front-loaded and every word contributes.
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 delete tool with two schema-documented parameters, the description provides the essential purpose and constraints. It does not explain error behavior or side effects, but given the lack of output schema and low complexity, it is reasonably complete, though not exhaustive.
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 both parameters (milestone_id, order) at 100% coverage. The tool description adds no additional parameter-specific details beyond what the schema provides, so the 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 states the tool's function with a specific verb ('Delete') and resource ('a checkpoint from a milestone'), distinguishing it from sibling tools like add_checkpoint, update_checkpoint, and complete_checkpoint.
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 an explicit when-not-to-use restriction: 'Cannot delete completed checkpoints or checkpoints that others depend on.' However, it does not mention alternative sibling tools (e.g., update_checkpoint) or a broader when-to-use context beyond the purpose statement, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only listing operation and describes the output shape, which is transparent for a simple list tool. However, it does not mention pagination, filtering, or permission requirements, which would add further 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 two concise sentences, front-loaded with the action ('List all members of a Clink group') and followed by the output summary. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter, the description is adequate: it states the purpose and the output fields. It lacks mention of edge cases like inactive members, ordering, or pagination, but these are not critical for a basic list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the 'group' parameter with a clear description (slug or ID). The tool 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 clearly uses the specific verb 'List' with the resource 'members of a Clink group', distinguishing it from sibling tools like list_groups or get_proposal. It also specifies the output fields (member names, roles, and join date), 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing group membership ('List all members of a Clink group'), but it provides no explicit when-to-use guidance or alternatives. There is no mention of when not to use the tool or comparison with sibling tools.
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 indicates a list operation (read-only) by the verb 'List' and mentions return content (progress/status), but does not explicitly disclose permissions, safety, or data scoping (e.g., filtering by status). Lacks explicit reassurance of no 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?
Two sentences, front-loaded with the core action, no waste. Every sentence contributes to purpose or output behavior.
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 simple list nature and full schema coverage, the description covers purpose and return semantics (progress/status). It doesn't mention filter options or defaults, but those are present in the schema. For a tool with no output schema, this is adequate, though it could explicitly mention the group parameter's role.
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 detailed descriptions for group, limit, and status. The tool description adds no parameter-specific meaning beyond what the schema already provides, so 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?
Description clearly states 'List milestones for a Clink group', a specific verb+resource+scope. This distinguishes it from sibling tools like get_milestone (singular) and create_milestone. The added 'Shows progress and status of each milestone' further clarifies purpose.
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?
It implies usage: use when you need all milestones for a group. However, it doesn't explicitly contrast with alternatives like get_milestone or mention when not to use. The context is clear but exclusions are absent.
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 the state transition (closed -> open) and intended use, but not edge cases like behavior if the milestone is already open, permission requirements, or side effects on existing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences precisely state the action and its purpose with no filler or repetition. Every sentence earns its place.
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 one-parameter state-transition tool, the description provides enough purpose and usage context without needing an output schema. It could mention error conditions, but the low complexity makes it 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 covers 100% of the single parameter with a clear description ('The milestone ID to reopen'), meeting the baseline. The tool description adds no additional parameter context 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 uses a specific verb 'Re-open' with resource 'milestone', clearly distinguishing from sibling tools like create_milestone and reopen_project. It also states the functional effect (allowing checkpoints to be added/completed), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explains when to use it: after a milestone is closed and there are remaining checkpoints or additions needed. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an important behavioral trait: clinks are visible to all group members unless addressed to a specific recipient. However, it does not mention other behavioral aspects such as permission requirements, whether sending is reversible, or what response is returned. The disclosure is meaningful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary verb and resource. It conveys the core action, the default visibility rule, and the optional parameter behavior without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple send action with fully documented parameters and no output schema, the description covers the main purpose, visibility semantics, and optional recipient behavior. It does not explain error conditions or prerequisites, but these are not critical given the low complexity and the schema's completeness.
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 three parameters are already documented. The description adds no new parameter-level semantics beyond paraphrasing the 'for' parameter as 'specific recipient' and reinforcing the group context. It does not introduce additional formats, constraints, or relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a clink') and the resource ('to a Clink group'), with added detail about visibility to all group members and optional recipient addressing. This is specific and distinguishes the tool from sibling operations like get_clinks or complete_clink.
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 implies when to use the tool (when sending a new clink) and explains the visibility consequence ('visible to all group members'), which helps decide whether to set the 'for' parameter. It does not explicitly name alternative tools for reading or managing clinks, but the context is sufficient for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals the key behavioral trait: claiming locks the clink against other workers and expires after a default timeout. It does not describe what happens if a clink is already claimed, but the core safety semantics are well covered.
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 action and purpose, with no filler. The timeout and expiry details are valuable and compactly stated.
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 claim tool with two parameters and no output schema, the description covers purpose, exclusivity, and expiry, which are the essential aspects. It lacks explicit conflict/error semantics (e.g., what happens if the clink is already claimed), but overall it is sufficient for an agent to decide to invoke it.
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%, and the timeout_seconds parameter already includes its default in the schema. The description only restates the default 5-minute timeout, adding no new 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'claim' with the resource 'clink' and clearly explains the purpose: to indicate processing and prevent concurrent processing by other workers. It distinguishes this from sibling tools like complete_clink and release_clink by focusing on the initial locking action.
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?
It explicitly states when to use the tool (before processing) and notes the expiry and release behavior, giving clear operational context. However, it does not directly name alternatives like release_clink or complete_clink or state when not to use it, so it falls just short of full alternative guidance.
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 states the core action and its purpose, implying a state change, but does not disclose side effects, permission requirements, reversibility, or the response format. This is a gap for a mutating tool, though the description is more informative than a bare one-liner.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, then a brief rationale. No redundant information. Each clause contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the core behavior and use case. It could mention what happens after reopening (e.g., status change), but for this complexity level it is adequately complete.
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 schema describes project_id generically. The description adds important semantic constraint: the project must be completed or archived to be reopened. This guides the agent on valid target states, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Re-open') with a clear resource ('a completed or archived project'), and distinguishes from sibling tools like 'reopen_milestone' by targeting projects. It also explains the intended result, adding new milestones or continuing work.
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: it is for projects that are completed or archived and when you need to add milestones or continue work. It doesn't explicitly mention alternatives or exclusions, but 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals an important behavioral trait: 'Requires an API key with feedback permission enabled' and details potential error handling ('If you get a permission error, ask the user...'). It also states the feedback goes directly to Voxos. It does not describe the result of a successful submission, but for a simple submission tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses clear formatting (bolded important note, bulleted categories). Every sentence earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and rich input schema, the description is largely complete. It covers purpose, permission requirements, and category usage. It lacks an explanation of the response or post-submission behavior, but this is not critical for a feedback submission tool. No output schema exists, so a brief note on what happens next could be beneficial, but its absence does not significantly hinder accurate 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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining each category in more depth than the schema (e.g., 'bug: Report something that isn't working correctly'), but it does not significantly enhance the semantics of 'content' or 'tool' 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?
The description clearly states the tool's purpose: 'Submit feedback to help improve Clink' with specific actions: 'report bugs, request features, or suggest improvements directly to Voxos.' This distinguishes it from all sibling tools, which focus on proposals, milestones, clinks, etc., none of which involve feedback submission.
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 on when to use the tool via its category definitions (bug, feature, improvement, other) and includes a critical prerequisite (API key with feedback permission). It does not explicitly exclude alternatives or name when not to use it, but given the distinct nature of feedback vs. sibling tools, this is a minor omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: projects become hidden from default views, the action is reversible ('can be reopened later'), and there is a restriction on the default project. This goes beyond a bare mutation statement and gives the agent a solid understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and every sentence contributes relevant information: the action, the effect, the reversibility, and a constraint. No unnecessary words.
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 (one parameter, no output schema, no annotations), the description is complete. It covers the action, post-condition, reversibility, and an important constraint. An agent can confidently select and invoke this tool based on this description alone.
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 one parameter (project_id) with a description, and the schema description coverage is 100%. The tool description does not add any additional parameter details or syntax, so the 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 starts with a specific verb and resource: 'Archive a project.' It clearly states the main effect (hidden from default views) and distinguishes itself from sibling tools like complete_project by noting the project 'can be reopened later.' This 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to archive: to hide a project while keeping it reopenable. It also gives an explicit exclusion: 'Cannot archive the default project.' However, it does not explicitly name an alternative tool like reopen_project, though it implies reversibility. This is clear usage guidance without fully naming alternatives.
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 discloses the output fields, but doesn't explicitly state that this is a read-only operation or discuss potential limitations like pagination or permissions. For a simple list tool, this 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 two concise sentences. It front-loads the action and resource, then lists the return fields. Every word adds value 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 (no parameters, no output schema), the description is fully complete. It states what the tool does and exactly what it returns, which is sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers 100% of them (vacuously). The description correctly omits parameter details, as there are none to explain. The baseline for zero params is 4, which 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 lists groups the user belongs to, using the specific verb 'list' and the resource 'Clink groups you belong to'. It also specifies the returned fields (slugs, names, descriptions, role), distinguishing it from sibling tools like list_members or get_clinks.
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: use it when you need to see groups you belong to and your role in each. It doesn't explicitly mention alternatives or exclusions, but the 'you belong to' scoping makes the usage situation obvious.
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 behavioral disclosure. It explicitly states the default behavior (addressed to you or unaddressed) and the side effect of auto-claiming (to prevent duplicate work). It does not mention any other side effects (e.g., whether claiming is reversible), but the key behavior is 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?
Two concise sentences front-load the primary purpose and then clarify defaults and the optional claim behavior. Every clause adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters with full schema coverage and no output schema, but the description adequately conveys that it returns clinks and highlights the important filtering defaults. It could mention the return format or that status defaults to pending, but this is covered in the schema. It is complete enough for an agent to invoke correctly without confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented. The description goes beyond the schema by explaining the purpose of auto-claiming ('prevent duplicate work') and the default for for_me. This extra context helps the agent decide when to set claim=true, adding value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and resource ('your inbox') and clearly distinguishes from sibling tools like get_clinks by focusing on clinks addressed to you or unaddressed. It also introduces the auto-claim capability, which makes the tool's scope unmistakable.
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 implies when to use it: to view pending clinks in your personal inbox, and when to use auto-claim (when you intend to process them to prevent duplicate work). It doesn't explicitly contrast with get_clinks, but the context is sufficiently clear for an agent to select this tool over general listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the key side effect: the clink returns to the pending queue for another worker to process. It does not mention permission requirements or reversibility, but the primary behavioral trait 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 two sentences with zero waste. The first sentence states the action, the second explains the consequence and gives usage guidance. Every word earns its place, and the structure is front-loaded with the action verb.
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 single-parameter action tool with no output schema and no annotations, the description covers the action, effect, and appropriate usage scenario. It adequately contextualizes the tool within the clink workflow (claim→complete/release). Minor gaps like return value or error conditions are not critical given the tool's simplicity.
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 schema covers clink_id with 'The clink ID to release' (100% coverage), so baseline is 3. However, the description adds meaningful semantic context that the clink must be 'claimed' and that releasing is 'without completing it', which enriches the parameter's implied state beyond the schema. This justifies a score above baseline.
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 'Release' with a clearly defined resource ('a claimed clink') and explicitly states it is 'without completing it', distinguishing it from complete_clink. The second sentence reinforces the purpose by explaining the clink returns to the pending queue, making the tool's function unambiguous.
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 explicit when-to-use guidance: 'Use this when you cannot complete the task.' It implies the alternative (complete_clink) by stating 'without completing it', but does not name it directly or offer explicit when-not-to-use conditions. This gives clear context though not full alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It lists the exact returned data: the list of permissions with [x] or [ ] markers, API key scope, and user/agent profile. This gives the agent a clear model of what to expect without side effects. It does not explicitly state that the operation is read-only, but the nature of a permissions checkimplies it, and the return details add meaningful 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 two sentences plus a bulleted list. Every sentence earns its place: the purpose, the usage, and the return value details. It is front-loaded with the main verb and resource, and the bullets improve scannability without unnecessary fluff.
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?
The tool is simple (no parameters, no output schema) and the description fully explains what it does and what it returns. The context is complete for an agent to select and invoke this tool correctly. Sibling tools are all different operations, so no additional context is needed to disambiguate.
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 per the rubric the baseline is 4. The description does not discuss parameters because there are none to discuss, and the empty input schema fully conveys that no arguments are needed. No additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Get the permissions granted to your API key.' This clearly distinguishes it from sibling tools that deal with proposals, projects, milestones, and other operations. The purpose is immediately obvious and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to check what operations you're allowed to perform,' which is a clear when-to-use statement. It does not mention alternatives or exclusions, but none are necessary given the unique nature of the tool. The guidance is direct but could be enhanced by noting it is a prerequisite for understanding authorization before using other tools.
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:

[![clink-mcp-server MCP server](https://glama.ai/mcp/servers/Voxos-ai-Inc/clink-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Voxos-ai-Inc/clink-mcp-server)

Score Badge

Copy to your README.md:

[![clink-mcp-server MCP server](https://glama.ai/mcp/servers/Voxos-ai-Inc/clink-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Voxos-ai-Inc/clink-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/Voxos-ai-Inc/clink-mcp-server'

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