ccontext

by ChesterRa

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.12
Disambiguation5/5
Each tool targets a distinct entity and action: tasks, milestones, notes, references, presence, and context. The batch tool commit_updates is clearly distinguished as a multi-op alternative to the single-purpose tools, reducing ambiguity.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., list_tasks, create_milestone, add_note, remove_reference). Minor verb variations (add vs create, remove vs delete) correspond to natural language for each entity but maintain the same structure.
Tool Count4/5
21 tools is on the higher end but appropriate for the broad scope of project context management (context, tasks, milestones, presence, notes, references). Each tool serves a distinct purpose, though some could theoretically be folded into commit_updates.
Completeness5/5
The tool surface covers the full lifecycle of each core domain entity: CRUD for tasks, milestones, notes, and references; presence management; and vision/sketch updates. The batch commit_updates fills any gaps for atomic multi-entity updates, and get_context provides a comprehensive view for resuming work.
Average 4.1/5 across 21 of 21 tools scored. Lowest: 3.1/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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions a benefit ('keeps progress accurate') and does not disclose effects on unspecified fields, partial update behavior, or any preconditions. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary action ('Update task execution state'), and includes a benefit clause. It is concise and free of fluff, though the vagueness of 'details' slightly reduces precision. It earns a solid score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description is insufficient. It does not explain step update semantics, how to unlink a milestone, or what occurs after the update. The tool's complexity demands more detailed guidance beyond the current one-liner.
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 each parameter. The description adds only a high-level grouping ('status/steps/details') and does not deepen understanding of parameters like step_id/step_status relationships or milestone linking behavior. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as updating task execution state, covering status, steps, and details. It distinguishes itself from sibling tools like create_task/delete_task and update_milestone by focusing on task execution state, though the term 'details' is somewhat vague.
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 keeping progress accurate during handoffs and resumption, giving some context. However, it does not explicitly name alternatives or state when not to use this tool, so usage guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that TTL decays and auto-archives over time, providing insight into the note's lifecycle. It also gives recommended TTL tiers. However, it does not explicitly state that this is a write/mutation operation, and without annotations, this is a notable gap. It also does not mention potential side effects or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with two sentences plus an example, and front-loads the core purpose. The example is useful but adds a bit of length; still, every sentence contributes value.
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 (two parameters, no output schema), the description covers the key aspects: purpose, TTL behavior, and an example. It does not explicitly state return values or error conditions, but for a straightforward add operation, these omissions are not critical.
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 already describes both parameters (content and ttl) with 100% coverage. The description adds a concrete example and explains the meaning of TTL tiers in context, which enhances understanding beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Preserve important knowledge' which clearly indicates the tool's function of adding a note for future reference. It distinguishes itself from sibling tools like update_note and remove_note by focusing on preservation. However, it does not explicitly use the verb 'add' or mention 'note', which slightly reduces precision.
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 its use for storing lessons, warnings, and decisions for future sessions, but it does not explicitly contrast with alternatives like add_reference or provide exclusion criteria. The context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose side effects, but it does not. It states the rule 'Exactly one milestone should be active at a time' but doesn't clarify whether the tool enforces this or merely advises the user, nor what happens to an existing active milestone when a new one is created.
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 a clear verb-adverb-noun structure and no filler. The key constraint is front-loaded after the action, making it easy to scan.
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 description covers purpose and usage, but given the 'exactly one active' rule, it doesn't explain the operational behavior (e.g., auto-deactivation, validation). Since there is no output schema or annotations, these gaps make the tool slightly ambiguous for an agent.
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 all three parameters with descriptions, so the baseline is 3. The description adds context by explaining milestones are coarse phases of 2-6 stages, which helps interpret the name parameter, but it doesn't add new details about status or description beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Start a new coarse project phase (timeline)', which clearly identifies the action and resource. The word 'coarse' distinguishes it from task-level tools like create_task, and the example 'Phase 1: Core Implementation' reinforces the intended scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for 2–6 big stages', providing a concrete sizing guideline. It stops short of naming alternatives or specifying when not to use it, but the coarse-vs-fine distinction is implied by 'coarse project phase' versus sibling tools like create_task.
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 bear the full burden of behavioral disclosure. It mentions 'prevent decay' which implies ttl decreases over time, but does not disclose whether ttl and content can be set simultaneously, what happens if the note does not exist, or any side effects. The 'or' phrasing is ambiguous regarding exclusivity.
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, directly front-loaded with the core purpose and a usage hint. No wasted words; every phrase carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with no output schema and no annotations, the description covers the basic purpose and a key use case. However, it lacks details about parameter combinability, error behavior, and return values, leaving notable gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions, so baseline is 3. The description adds context that ttl relates to decay, but does not clarify parameter interactions (e.g., whether ttl and content can both be provided). No significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's action: 'Refresh a note's ttl to prevent decay, or update its content.' It names the resource (note) and the specific operations (ttl refresh and content update), which distinguishes it from sibling tools like add_note and remove_note.
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 context for when to use the ttl refresh functionality: 'Use when a note is still valuable but its ttl is getting low.' However, it does not give equivalent guidance for the content update use case or mention when not to use this tool, falling short of a 5.
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?
Since no annotations are provided, the description carries the transparency burden. It adds a key behavioral trait: outcomes become permanent project history visible to future sessions, implying irreversibility. But it does not disclose side effects like whether the milestone becomes locked, permission needs, or what happens on errors.
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 optimally concise: two sentences, the first stating the core action, the second noting the key consequence. Every word adds value, making it highly scannable and information-dense without 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 simple 2-parameter tool with no annotations or output schema, the description covers the primary action and the permanence of outcomes. However, it omits details about return values, error conditions, or whether a completed milestone can be reopened, leaving some gaps for a tool that records lasting history.
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 coverage is 100% but generic ('Results summary' for outcomes). The description enriches the outcomes parameter by stating it records 'what was accomplished' and becomes permanent, giving it contextual meaning beyond the schema. Milestone_id remains self-explanatory but no additional elaboration 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 states a specific action (close) on a specific resource (milestone) and adds the purpose of recording accomplishments. This clearly distinguishes it from siblings like update_milestone or remove_milestone, and the permanence note frames its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage timing is implied: use when a milestone is done and needs to be closed with outcomes recorded. However, there is no explicit 'when to use vs. alternatives' or exclusion of update_milestone, leaving some ambiguity about the exact boundary between this and other milestone 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 provided, so the description carries full burden for behavioral disclosure. It identifies the action as a destructive delete but does not state whether deletion is permanent, reversible, or if there are any side effects, permissions, or blocking conditions. The note about completed milestones implies a constraint but does not explicitly state what happens if attempted.
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 free of filler. Every word earns its place, conveying purpose and usage constraint efficiently.
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 single-parameter delete tool, the description covers purpose and usage adequately. However, the lack of any behavioral details (e.g., irreversibility, refusal conditions) leaves gaps, especially given no annotations or output schema exist to supplement.
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 ('Milestone ID to remove'). The tool description adds no additional meaning beyond what the schema already provides, so 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 clearly states the tool deletes a milestone, specifically for 'cancelled or mistaken' ones. It distinguishes from sibling tools like complete_milestone by noting completed milestones should be kept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: use for cancelled or mistaken milestones, and do not use for completed milestones since they serve as project history. This effectively differentiates from complete_milestone and update_milestone.
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 traits. It states the action (create) and offers a structural constraint (3–7 steps), but does not mention permissions, idempotency, side effects, or what happens on success or failure. 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 description is two sentences, front-loaded with the core purpose, and every word adds value. It avoids redundancy and is well-structured, making it easy for an agent to quickly grasp the tool's intent and key usage nuance.
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?
Despite no output schema and no annotations, the description covers the essential context: what the tool creates, its intended use case, and a key best practice. Given the schema already describes all parameters, the description adds sufficient situational context to enable correct invocation, though it could mention additional constraints or outcome details.
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 description coverage is 100%, providing a baseline of 3. The description adds extra meaning by specifying the 3–7 step count for the 'steps' parameter and recommending the use of 'milestone_id', which goes beyond the schema's simple field descriptions. It thereby enhances parameter understanding.
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: 'Create a deliverable work item with 3–7 steps.' It specifies the resource (work item) and the action (create), and the phrase 'Use for concrete outcomes that span handoffs or need tracking' differentiates it from simpler task-related tools. This distinguishes it from siblings like update_task and delete_task.
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 ('Use for concrete outcomes that span handoffs or need tracking') and offers a preference ('Prefer linking it to a milestone via milestone_id'). However, it does not explicitly state when not to use it or name alternatives, so it stops short of full 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 provided, the description carries the full burden of behavioral disclosure. It implies a read-only list operation by saying 'Find tasks' and 'see what work exists,' but it does not explicitly state that it is non-mutating, nor does it mention any permissions, rate limits, or response format. It adds some context with 'across sessions' but leaves out details like whether archived tasks are excluded by default (though the schema covers that).
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. The first sentence states the core function and filters; the second gives the intended use case. There is no redundant information, and the most important information is front-loaded. It earns its place completely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with 100% schema coverage and no output schema, the description is sufficiently complete. It states the primary filters and the use case. It could additionally mention that task_id lookup is supported, but the schema clarifies that. The description differentiates from sibling tools well and stands alone as understandable.
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 minimal value by rephrasing 'status' and 'assignee' filters, but it does not mention task_id or include_archived, which are already documented in the schema. The schema descriptions are clear and self-sufficient, so the description does not need to compensate.
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: 'Find tasks by status (planned/active/done) or assignee.' It clearly identifies the tool's function and distinguishes it from sibling tools like create_task, update_task, and get_context by focusing on listing/filtering tasks. The additional purpose statement ('Use to see what work exists and check progress across sessions') further clarifies its role.
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: 'Use to see what work exists and check progress across sessions.' This implies a read-only, overview-oriented usage. It does not explicitly list exclusions or alternatives, but the purpose is strong enough to guide an agent, especially given the sibling tools are mostly mutations or context queries.
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 adds context about ttl decay and the 'still valuable' scenario, but does not disclose side effects, permissions, or behavior when the reference_id is invalid or missing. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the primary purpose. Every word earns its place, making it highly concise and easy to scan.
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?
Despite lacking an output schema, the description covers the core functionality and usage scenario adequately. It does not explain return values, but for an update operation with a clear schema, this is not a significant gap. The description is complete enough for the tool's simplicity.
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% for all four parameters, so the schema fully documents each field. The description does not add new semantics beyond the schema, merely referring to 'update its details' without naming url or note individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose with specific actions: 'Refresh a reference's ttl to prevent decay, or update its details.' It clearly identifies the resource (reference) and the two distinct operations, distinguishing it from sibling tools like add_reference and remove_reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use when a reference is still valuable but its ttl is getting low.' This tells the agent when to invoke the tool, though it does not explicitly mention when not to use it or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose important execution behaviors such as atomicity, failure handling, ordering guarantees, or return format. It explains the input shape and supported ops but leaves the AI agent unaware of what happens when an op fails or if partial application is possible. This is a significant transparency gap for a mutating batch 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 long but efficiently structured as a bulleted list of ops with a clear example at the end. It front-loads the core purpose, then organizes the many operations in a scannable format. Every line conveys necessary details without redundant prose, making it optimally concise for its complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (covering 10+ operation types), the description thoroughly covers the input contract: all supported ops, their fields, optional markers, recommended values, and an example. However, it omits any information about the return value or error/failure behavior, which is notable because there is no output schema to fill that gap. It is nearly complete for invocation but not for post-call expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines ops as an array of objects with a required 'op' string, leaving the actual parameters as an open object. The description compensates by providing the full parameter list for every op (e.g., note.add: content, ttl?), indicating required vs optional with '?', recommending ttl values (10/30/100), and giving a concrete example. This is essential information the schema does not provide.
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 'Apply multiple updates in ONE call' and then enumerates the supported operation types (e.g., context.set, task.update, note.add). This specific verb+resource combination distinguishes it from the individual sibling tools, which each handle a single operation.
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 positions the tool as a batch alternative by noting it 'reduces friction; keeps context current' and lists all operations it can perform. This implies it should be used when multiple updates are needed, but it does not explicitly state when to prefer this over individual tools or provide any exclusions/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.
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 states the core action (modify, advance status) and the allowed status sequence (pending→active→done). However, it does not disclose permissions, reversibility, partial update behavior, or what happens if a backward transition is attempted. This is a moderate disclosure but leaves significant 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 is front-loaded with the primary verb ('Modify') and immediately conveys the key capabilities. Every phrase adds value, and the parenthetical status sequence is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must be self-sufficient. It covers purpose and use cases, but it does not clarify how it differs from sibling complete_milestone, nor does it mention partial update semantics or response format. Given the 100% schema coverage, it is adequate but not 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?
Schema coverage is 100%, so baseline is 3. The description adds meaning by mapping 'phase scope/outcomes' to name/description fields and explaining the status transition sequence. This goes beyond the bare schema descriptions and helps the agent understand the intent of each parameter.
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: 'Modify milestone details or advance status (pending→active→done)'. It specifies the resource (milestone) and the actions (modify details, advance status), distinguishing it from siblings like update_task or update_vision. The mention of phase transitions and scope/outcomes further clarifies its unique role.
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 usage context: 'Use to mark phase transitions or adjust phase scope/outcomes.' This tells the agent when to use the tool. However, it does not mention alternatives or exclusions, such as when to use complete_milestone instead, so it lacks the 'when-not-to-use' guidance that would earn a 5.
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?
Without annotations, the description carries the burden of disclosing behavior. It mentions 'TTL decays over time' and provides recommended tiers, which is a key behavioral trait. However, it does not explain what happens when TTL expires, whether the reference is automatically removed, or any side effects like persistence or duplicate handling. The description is adequate but leaves significant behavioral details unspoken.
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, consisting of five short sentences, each serving a distinct purpose: purpose, TTL decay, recommended tiers, use cases, and an example. The most critical information is front-loaded, and every sentence earns its place without redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with 3 parameters and no output schema, the description is reasonably complete. It covers purpose, usage context, and a critical behavioral detail (TTL decay). It omits information about the return value (e.g., a reference ID) and any post-creation behavior, but these may not be essential for a straightforward add operation. The sibling set (update_reference, remove_reference) implies CRUD context.
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 the baseline is 3. The description adds a concrete example of note formatting ('src/core/auth.py - OAuth implementation') and reinforces the intended use of the url parameter as file paths or URLs. It also repeats TTL tiers that are already in the schema, but the example and use cases provide practical guidance 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 'Bookmark' and clearly identifies the resource as 'file paths or URLs'. It provides use cases ('key source files, API docs, configs') and a concrete example, which helps distinguish this tool from siblings like add_note or update_reference. The example format makes the intended content 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 gives clear context via 'Use for: key source files, API docs, configs' and implies the tool is for storing navigational references. However, it does not explicitly state when not to use it or mention alternatives (e.g., add_note), so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains that the tool clears the presence status to prevent stale statuses from misleading others, which is the key behavioral trait. It does not mention side effects or reversibility, but for a simple clear operation 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 two concise sentences, front-loaded with the action and purpose. Every sentence adds value, with no filler or repetition of the schema.
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) and the clear explanation of when and why to use it, the description provides sufficient context. It could optionally mention the return value or effect on other agents, but this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter agent_id, including an example. The description itself adds no extra parameter context, so it meets the baseline of 3 without exceeding it.
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 'Clear' and the resource 'presence status', and explicitly clarifies 'remove stale/finished status'. This differentiates it from sibling tools like get_presence (read) and update_my_status (set), 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?
It provides explicit when-to-use guidance: 'Use this when you’re done or after a handoff'. It does not explicitly mention when not to use or recommend alternatives, 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?
No annotations are provided, so the description carries the full burden. It adds context about completed tasks auto-archiving, which helps clarify the lifecycle. However, it does not disclose whether deletion is permanent, what happens to associated data, or any prerequisites/effects beyond the act of removal. This is a gap for a destructive operation with no annotation support.
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 purpose and followed by a relevant contextual note. It contains no redundant filler and every sentence contributes meaningful guidance.
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 delete tool with no output schema, the description covers the main purpose and usage conditions (cancelled/mistaken vs completed). It could be more complete by stating whether deletion is permanent or if there are side effects, but overall it adequately orients the agent for the tool's scope.
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 for the single parameter (task_id) with a clear description. The tool description adds no additional information about the parameter beyond re-stating the purpose, 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 uses a specific verb ('Remove') and resource ('task'), clearly scoped to 'cancelled or mistaken' tasks. It distinguishes itself from siblings like update_task, create_task, and remove_milestone by making the deletion purpose explicit and different from other task-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/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 (for cancelled or mistaken tasks) and when not (completed tasks auto-archive after 7 days, so no need to delete them). While it doesn't name an alternative tool, the auto-archive guidance serves as an alternative path, making the usage context clear.
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 side effects. It states the tool deletes a note, which implies destructive action, but does not mention irreversibility, cascading effects, or permission requirements. The TTL preference hints at lifecycle context but lacks depth on what 'decay' means operationally.
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. The first states the action and object, the second provides usage guidance. 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 tool with one parameter and no output schema, the description covers what the tool does and when to use it. Minor gaps include not explaining what happens to related data (e.g., references) or whether deletion is soft or hard, but the tool is simple enough that these may not be critical.
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 the parameter 'note_id' described as 'Note ID to remove', so the schema already provides clear semantics. The description adds no further detail about the parameter, such as format or source, but does not need to given the high 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 identifies the action ('Delete') and the target resource ('note'), and adds 'immediately' to indicate urgency. It distinguishes itself from sibling tools like add_note and update_note by focusing on deletion, and the ttl reference hints at a lifecycle context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly advises when to use this tool versus alternatives: prefer natural TTL decay for low-value notes, implying use remove_note only for notes requiring immediate deletion. This is clear, actionable 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 full responsibility. It does disclose that deletion is immediate and contrasts with TTL-based decay, adding behavioral context. However, it does not mention permanence, reversibility, or required permissions, which are relevant for a delete operation.
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 action, and the second sentence supplies usage guidance. Every word contributes value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and no annotations, the description covers the core purpose, the immediate action, and the preferred alternative (TTL). It lacks explicit details on irreversibility or side effects, but given the tool's simplicity and sibling context, it is nearly 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% because the only parameter reference_id is described as 'Reference ID to remove.' The description itself does not add any parameter-specific guidance beyond what the schema already states, so it stays at the baseline for full 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 starts with a specific action 'Delete an obsolete reference immediately,' clearly identifying the resource (reference) and the verb (delete). It distinguishes itself from sibling tools like remove_note and remove_milestone by specifying 'reference' and adds context with 'obsolete' and 'immediately.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Prefer letting outdated references decay naturally via ttl lifecycle.' This clearly states when not to use the tool and names the alternative (TTL lifecycle), making the usage conditions unambiguous.
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 burden. It states the operation ('set or update') and adds context that the vision is a short, fixed statement, but it does not disclose whether updates replace the existing vision or any other side effects. For a simple setter, this is minimal but not misleading.
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 compact and front-loaded with the core purpose. It uses two sentences plus an example, with no redundant words or repetition of schema details. Every part contributes value.
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 required param, no output schema), the description is sufficiently complete. It covers purpose, format, and an example. It could be slightly more explicit about what happens on update (e.g., overwrite), but the provided context is adequate for an agent to 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 schema has 100% coverage for the single parameter, so the baseline is 3. The description adds meaningful nuance: it clarifies that the vision should be a 'short, fixed statement' and provides a concrete example, which goes beyond the schema's basic 'Project vision statement'.
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 ('Set or update') and identifies the exact resource ('project vision') with clarifying context ('what we're building'). It clearly distinguishes from sibling tools like update_sketch and update_my_status by focusing on the project-level vision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when setting or updating the overarching project vision, and clarifies that it is a short, fixed statement. It does not explicitly mention alternatives or when-not-to-use, but the specificity of 'project vision' differentiates it well from siblings.
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 transparency burden. It explains the purpose (informing other agents), suggests content length (1-2 sentences), and gives examples. It doesn't mention overwriting or permissions, but for a simple status update, these are not critical 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 compact and well-structured, using bold for emphasis and including practical examples without any redundant sentences. Every part contributes to understanding the tool.
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 tool with two parameters and no output schema, the description is complete. It covers the purpose, when to use it, what to include in the status, and provides examples. No significant information gap remains.
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 the baseline is 3. The description adds examples for the status parameter but doesn't provide new meaning for agent_id beyond the schema's 'Your agent ID'. Overall, it modestly enriches the schema description.
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 ('Tell other agents what you're doing') and its resource (your status), making it distinct from sibling tools like get_presence or clear_status. Examples further clarify that the status should describe current focus, intent, or blockers.
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 conveys when to use the tool ('they can't see your work otherwise') and provides concrete examples for typical scenarios. However, it doesn't explicitly contrast with alternative status-related tools like update_vision, leaving the differentiation implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It reveals cross-session persistence, shared updates by other agents, and the exact return envelope (version, now, diagnostics, warnings/hints), which is significant unobservable behavior beyond a simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although longer than a one-liner, the description is dense and well-structured: a front-loaded warning, a list of contained fields, and a clear explanation of return fields. Every clause contributes meaningful information without repetition or filler.
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 zero-parameter, no-output-schema tool, the description fully covers what the agent receives, why it matters, and when to consult it. It also explains the collaborative nature (shared memory) and the diagnostics/warnings features, making the tool self-contained for an agent.
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 takes zero parameters, so the schema already fully covers parameter expectations. The baseline of 4 applies because there are no parameter details to explain; the description appropriately focuses on the output and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states what get_context does: it returns the persistent execution memory containing vision, sketch, milestones, tasks, notes, and references. The verb 'Read this first' plus the enumerated contents clearly distinguishes it from specific sibling tools like list_tasks or get_presence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it ('Read this first', 'check regularly') and notes that other agents update it, explaining the coordination benefit. It does not explicitly state when not to use it or name alternative tools, but the guidance is strong enough for selection.
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 transparency burden. It explicitly states the output fields (ID, status, last update time) and the natural-language nature of status, going beyond the tool name to inform the agent about what to expect. It doesn't cover edge cases or failure modes, but for a simple read operation 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 three short sentences, each earning its place: first states the action, second notes the use case, third specifies the return structure. No redundancy or filler.
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 zero-parameter read tool with no output schema, the description clearly defines what the returned data looks like (per-agent ID, status, timestamp). It provides enough information for an agent to decide when to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameter meaning, and the schema confirms no required inputs. No additional parameter semantics are necessary.
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+resource ('Get all agents' current status') and clearly distinguishes itself from sibling tools by focusing on presence/status rather than tasks or milestones. The parenthetical 'what they're doing/thinking' adds useful specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Essential for multi-agent coordination' provides clear context for when to use, and the sibling list shows no other tool that retrieves presence info. It lacks explicit exclusions or alternatives, but the intended use is well implied.
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 provided, so the description carries the full burden. It adds valuable behavioral context about the sketch being 'static' and what it should/shouldn't contain. However, it doesn't explicitly state whether the update replaces the entire sketch or merges, which is a minor transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. Each sentence adds value: purpose, static nature, exclusions, recommended sections, and update triggers. No fluff or 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?
For a simple one-parameter update tool with no output schema, the description provides complete operational context: what it does, what content belongs, what doesn't, when to use it, and even recommended structure. The only minor omission is explicit replacement vs merge behavior, but that is largely implied by 'update' and the single full-blueprint parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage (100%) for the 'sketch' parameter. The description adds semantic depth by explaining the nature of the markdown (static blueprint) and recommending sections, enriching the parameter's meaning beyond the schema's basic type description.
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 'Update the execution blueprint (markdown)' with a specific action and resource. It explicitly differentiates from siblings by rejecting TODOs, daily progress, task lists, and milestone status, directing users to tasks/milestones instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Update on: architecture/strategy shifts or major risk changes.' Also gives when-not-to-use and names alternatives ('use tasks/milestones instead'), making the decision context unmistakable.
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:

[![ccontext MCP server](https://glama.ai/mcp/servers/ChesterRa/ccontext/badges/card.svg)](https://glama.ai/mcp/servers/ChesterRa/ccontext)

Score Badge

Copy to your README.md:

[![ccontext MCP server](https://glama.ai/mcp/servers/ChesterRa/ccontext/badges/score.svg)](https://glama.ai/mcp/servers/ChesterRa/ccontext)

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/ChesterRa/ccontext'

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