cs-agent-mcp

by codestable

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation4/5
Tools have clearly distinct roles with detailed descriptions, but the multiple wait/read variants (wait_message, wait_turn, get_message, get_turn, events) create some overlapping surface that could cause misselection without careful reading.
Naming Consistency4/5
All tools share the cs_agent_ prefix and use consistent lowercase_with_underscores, but the verb pattern is mixed: some are bare verbs (create, list, send, cancel, destroy) while others are verb_noun (get_message, wait_turn). This is still predictable and readable.
Tool Count5/5
14 tools is well within the optimal range and each tool serves a distinct need in the delegation lifecycle: capabilities, creation, messaging, waiting, permissions, cancellation, and destruction. The count feels appropriate for the domain.
Completeness4/5
The lifecycle is well covered: create, list, status, send, wait, cancel, destroy, plus capability discovery and permission handling. Minor gaps exist such as no explicit update_agent or non-turn messaging tool, but these are likely out of scope and core workflows are fully supported.
Average 4.4/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 46 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 failing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description reinforces this with 'is destructive' and 'releases the managed lifecycle'. It adds a little context about post-completion usage, but it does not disclose additional behaviors such as irreversibility beyond the hint, potential permission requirements, or what happens to associated resources. Since annotations carry the safety burden, the description only marginally adds value, matching the baseline.
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 purpose, and every phrase earns its place. The second sentence reinforces the destructive nature without unnecessary verbosity.
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 has 3 parameters (all documented in schema), destructive annotations, and no output schema, the description is sufficient for an agent to understand when and how to use it. It could mention the consequence of using cascade=false when descendants exist, but the schema already covers that. The description is complete enough for a destructive lifecycle 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 parameter schema has 100% description coverage, explicitly explaining agentId, cascade, and discardSession. The description paraphrases these as 'cascading through descendants' and 'discarding its session' but does not add new meaning beyond what the schema already provides. With the baseline of 3 for high schema coverage, this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Destroy a managed agent after its work is complete or abandoned'. It identifies the resource (managed agent) and the specific verb (destroy), and distinguishes this from sibling tools like cs_agent_cancel by indicating this is a final lifecycle action, not just a run-level cancellation.
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 explicit timing context: 'after its work is complete or abandoned'. This implies the tool should be used at the end of an agent's lifecycle, not while it is actively being used. However, it does not explicitly name alternatives like cs_agent_cancel for stopping in-flight work, so it lacks the full 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, so the description adds value by explaining optional live probes and listing what is included (agents, facade tools, limits). No contradiction with 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?
Two sentences, front-loaded with the key instruction, and every clause adds meaningful guidance. Zero waste.
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?
No output schema exists, but the description lists the kinds of information returned (names, probes, facade tools, execution limits), enough to set expectations for a read-only listing tool. Could be more detailed about output format but adequate.
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 has 100% coverage for the single parameter, so the description adds only marginal context about 'live availability probes' aligning with probeAgents. 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 lists configured agent names, probes, facade tools, and execution limits for delegation decisions. It uses a specific verb ('lists') and resource (capabilities), and distinguishes itself from sibling tools like cs_agent_list by emphasizing its decision-support 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?
Explicitly says 'Call first when considering delegation or heterogeneous execution', giving clear when-to-use context. Lacks explicit exclusions but provides strong precedence and decision 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?
Beyond the readOnly/idempotent annotations, it adds 'immutable-point-in-time' and 'without waiting,' disclosing snapshot semantics and non-blocking behavior. No contradiction.
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 and followed by a usage note. No redundant wording.
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?
A single-parameter read tool with readOnly annotations; the description conveys purpose, usage, and expected diagnostic scope. Return format is only hinted at, but given the simplicity, this is adequate.
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 fully covers turnId with a clear description; the tool description adds no parameter-specific information. 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 states 'Read one immutable-point-in-time turn snapshot by id' — a specific verb and resource, and explicitly frames its diagnostic purpose (state, revision, error, permission), distinguishing it from get_message/list.
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 says 'Use it for detailed state, revision, error, and permission diagnostics without waiting,' providing a clear use case and implying contrast with waiting tools, though it doesn't name alternatives.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond this: the scoping to the caller's delegation subtree, support for filtering and cursor pagination, and the explicit limitation that sibling or ancestor subtrees are not accessible.
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 clause adds value. It is concise without sacrificing necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, usage context, scoping limitation, and key capabilities (filtering, pagination). With no output schema, it does not describe return values, but this is acceptable for a list tool. Some additional details about combining filters could be useful, but overall it is complete enough for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description only generically mentions 'filtering and cursor pagination' without adding specific details about individual parameters, so it does not enhance the schema's 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 verb 'Inspect', the resource 'managed agents', and the specific scope 'caller's delegation subtree'. It also distinguishes itself from siblings by noting it cannot reveal sibling or ancestor subtrees, 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?
Explicit use cases are provided: 'before creating duplicates or when coordinating parallel work'. It also gives an exclusion: 'cannot reveal sibling or ancestor subtrees'. However, it does not explicitly name alternative tools, relying on the sibling list for that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint false) and non-destructive (destructiveHint false). The description adds that the agent is 'managed' and self-contained, implying lifecycle tracking, and mandates a prerequisite call. However, it does not disclose return values, failure modes, or resource implications, so only moderate transparency beyond 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?
Two sentences, direct, front-loaded with the action and purpose. No filler or redundant information.
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 5 parameters, a nested object, and no output schema. While the schema is detailed, the description omits what the tool returns (e.g., agent ID) and how to interact with the created agent via sibling tools. This is a notable gap for an AI 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?
Schema already covers 100% of parameters, so baseline is 3. The description adds value by explaining that the agent parameter must come from cs_agent_capabilities, complementing the schema's description of 'agent' as a configured local agent name.
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 it creates a managed child agent and specifies suitable use cases (parallel work, different runtime, specialization, independent review). It distinguishes from sibling messaging/status tools by focusing on the creation action.
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?
Explicitly instructs to call cs_agent_capabilities before choosing an agent, and warns against delegating trivial or tightly coupled work. This provides clear when-to-use and 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the immutability of messages and the fact that it reads a single message, but it does not disclose return format or error behavior. Given the annotation coverage, the incremental transparency is limited.
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 purpose and provide an explicit alternative. No 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 low-complexity with one parameter and thorough annotations. The description covers the operation, usage, and a key behavioral distinction. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description of messageId: 'Message id returned by send, wait, or an event.' The tool description adds the context of 'already have its id' but does not introduce new parameter semantics. Baseline of 3 is appropriate given 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 'Read one immutable delegated request or reply message when you already have its id.' This provides a specific verb and resource, and distinguishes from the sibling tool cs_agent_wait_message by naming it directly.
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?
Explicitly instructs when to use this tool versus the alternative: 'Use cs_agent_wait_message instead when waiting for an unfinished task.' This gives a clear when-not condition and names the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite the destructiveHint annotation already flagging destructiveness, the description adds meaningful context by specifying that 'unfinished descendant turns' are also canceled and warns to 'inspect status first,' going beyond the annotation's simple flag.
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 wasted words. The first sentence states the action and scope, the second adds a necessary caution. Every phrase 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?
With a simple schema and no output schema, the description adequately covers purpose, scope (including descendant turns), and a cautionary note. It could mention return behavior or error cases, but these are not strictly required.
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%: turnId and reason are already clearly described in the schema. The description does not add extra parameter-specific meaning or examples, so it meets the baseline 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 uses the specific verb 'Cancel' and identifies the resource as 'queued or active work, including unfinished descendant turns,' which clearly distinguishes it from sibling tools like cs_agent_destroy or cs_agent_send.
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 clear context for when to use the tool: for 'obsolete, unsafe, or no-longer-needed' work, and advises to 'inspect status first when the outcome is uncertain.' However, it does not explicitly name alternative tools or exclusion criteria.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe-read nature is established. The description adds meaningful behavioral context beyond annotations by mentioning the ability to 'briefly wait' (long-polling) and the 'opaque cursor' mechanism for incremental reads. No contradiction.
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 incredibly concise: two sentences, front-loaded with the core action and resource, immediately followed by usage guidance. Every word earns its place with no 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 polling tool with all-optional parameters and no output schema, the description covers purpose, usage context, cursor semantics, and the long-poll behavior. However, it does not describe the structure of the returned 'events' or ordering guarantees, which would be helpful given the absence of an output schema. Still, the overall context is adequate for an agent to select and invoke the 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 provides 100% description coverage for all five parameters, including detailed explanations for limit, turnId, waitMs, agentId, and afterCursor. The description adds minimal extra meaning beyond the schema, only reinforcing the 'opaque cursor' and 'wait' concepts, so a 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 verb ('Read or briefly wait') and the resource ('structured delegation events after an opaque cursor'). It distinguishes itself from sibling tools by explicitly contrasting with the 'reply-oriented cs_agent_wait_message call'.
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 provides explicit guidance on when to use this tool: 'Use for progress monitoring across agents or turns'. It also names the alternative (cs_agent_wait_message) and explains when that alternative is not sufficient, giving a clear decision rule.
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?
Annotations already signal destructive and non-idempotent behavior; the description adds contextual consequences: persistent outcomes affect later matching requests, and rejection/cancel can stop delegated work. It also reinforces 'least privilege' decision-making, going beyond what annotations convey.
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-loads the purpose, and includes only decision-relevant information. No filler or repetition of schema details.
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 two-parameter tool with full schema coverage, the description covers what the tool does, when it applies, and the decision philosophy. It doesn't explain return behavior, but with no output schema and low complexity this is not a critical gap.
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 fully documents both parameters with descriptions and enum values, so baseline is 3. The description adds value by explaining that permissionId comes from wait/status and by guiding outcome selection (prefer one-time approval), raising it 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 a specific verb ('Resolve') and identifies the resource ('pending permission request'), clarifying it is surfaced by wait or status. This differentiates it from sibling tools like cs_agent_cancel by focusing on permission resolution rather than general cancellation.
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 states when to use the tool: when a pending permission request is surfaced by wait or status. It provides guidance on choosing outcomes with the least-privilege principle and notes that rejection or cancel can stop delegated work, but it doesn't name explicit alternatives or give a when-not-to-use condition.
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?
The description adds valuable behavioral context beyond annotations: it explains that the idempotency key makes retries safe, revealing a key operational behavior. It also implicitly communicates async behavior by referencing cs_agent_wait_many. The annotations already provide readOnly, openWorld, idempotent, and destructive hints, so the description adds complementary operational context rather than contradicting them.
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 sentences, each serving a clear purpose: what the tool does, what to include and why, and when to use it in parallel workflows. It is front-loaded with the primary action, contains no filler, and is appropriately sized for the tool's 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?
The description covers the core task, content requirements, idempotency, and parallel usage. It does not explicitly state how to retrieve the result for a single send, but the reference to cs_agent_wait_many and the availability of sibling wait tools provide sufficient context. Given the tool's complexity and lack of output schema, this is nearly complete, though a direct pointer to the wait step would have been ideal.
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%, so the baseline is 3. The description goes further by explaining what should go into the 'content' parameter (objective, scope, constraints, expected deliverable, verification criteria) and clarifying the purpose of the idempotencyKey for safe retries. This adds practical meaning beyond the schema's per-parameter descriptions.
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 'Assign' with a specific resource ('managed descendant agent') and a concrete action (send a self-contained task). It distinguishes the tool from siblings like cs_agent_cancel, cs_agent_destroy, and cs_agent_get_message by focusing on task delegation. The instruction to include objective, scope, constraints, deliverable, and verification criteria further clarifies the 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 gives explicit guidance for parallel work: 'send all independent turns before waiting with cs_agent_wait_many,' which clearly indicates when to use this tool in a parallel workflow. It lacks an explicit 'when-not-to-use' or mention of alternatives for single-task waiting, but the context is sufficiently clear.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about the types of state changes to wait for (revision, permission request, terminal state), which goes beyond the annotations without contradicting them. It does not detail timeout behavior or return value structure, but enough context is provided for a wait 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 long, with the first sentence stating the core purpose and the second providing usage guidance. There is no redundant information or filler; every word 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?
Given the tool's simplicity (three scalar parameters, no output schema) and the presence of annotations, the description is largely complete. It explains the purpose and when to use it, which is sufficient. The term 'terminal state' is somewhat vague, and there is no mention of return values or error conditions, but these are not critical for a wait tool and the description otherwise covers the essentials.
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 each parameter (turnId, waitMs, afterRevision) clearly described in the schema. The tool description does not add additional meaning beyond what the schema already 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: waiting for a turn revision, permission request, or terminal state. It uses a specific verb ('Wait') and resource ('turn'), and distinguishes itself from the sibling tool cs_agent_wait_message by focusing on state transitions rather than reply content.
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 explicitly provides usage guidance: 'Use this instead of cs_agent_wait_message when state transitions matter more than reply content.' This tells the agent when to prefer this tool over an alternative, which is exactly what the dimension requires.
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?
The description adds behavioral context beyond the annotations by listing the specific state dimensions inspected (lifecycle, queue, pending permission, last error, runtime state). It aligns with the readOnlyHint and idempotentHint annotations, and does not introduce any contradiction. It doesn't detail the return structure but the annotations lower the burden.
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 every sentence adds value. The first sentence defines the scope, the second provides usage context. There is no wasted text.
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 (one parameter, read-only, no output schema). The description covers what it does and when to use it, and the annotations cover the safety profile. Given the low complexity and rich annotations, the description is sufficiently 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 schema already provides 100% coverage of the single agentId parameter, including its format and provenance ('Visible managed agent id returned by create or list'). The description does not add parameter-specific details, 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 the specific verb 'Inspect' and enumerates the aspects (lifecycle, queue, pending permission, last error, runtime state), clearly distinguishing it from sibling tools like cs_agent_create, cs_agent_send, and cs_agent_cancel. It also states its role in diagnosing a delegated task, making its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use it to diagnose a delegated task before deciding to wait, respond to permission, cancel, or retry.' This connects to probable sibling actions and provides clear decision context, effectively guiding the agent on when to invoke this tool vs. other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description reveals meaningful behaviors: mode 'any' returns all currently ready items, mode 'all' returns early on permissions or timeout, and interrupted all-waits require manual accumulation via pendingTurnIds. These details are not present in the schema and materially shape correct usage.
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?
Three sentences, front-loaded with the primary action, then mode details, then recovery guidance. No redundant words; every clause contributes to either understanding or usage. The structure flows logically from what to do, to mode behavior, to post-interruption handling.
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 polling utility with 3 parameters and no output schema, the description covers the essential workflow: issuing turns first, choosing modes, handling partial results, and resuming. It does not specify the exact return value format, but the description of 'ready items by turnId' gives adequate shape. Overall, sufficient for an AI agent to invoke 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?
Schema description coverage is 100%, so baseline is 3. The description adds semantic nuance to the 'mode' parameter by clarifying that 'any' returns all ready items, not just one, and introduces the concept of pendingTurnIds for handling interruptions—valuable context beyond the schema's terse 'returns when at least one turn is ready.'
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 a specific verb+resource: 'Wait for multiple turns,' distinguishing from sibling cs_agent_wait_turn. It immediately establishes the tool's role ('after you send all independent turns first') and elaborates mode semantics, leaving no ambiguity about its 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?
Provides explicit usage instructions: send independent turns first, then choose mode based on whether you want current ready items or to wait for all terminal. It also advises how to recover from interrupted 'all' waits by accumulating ready items and continuing with pendingTurnIds. Fails to explicitly name alternatives like cs_agent_wait_turn, but the context makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and idempotentHint=true, and the description adds significant behavioral context: it returns a terminal reply, a permission request requiring cs_agent_respond_permission, a terminal turn without a reply, or a bounded timeout. This goes beyond annotations and clarifies blocking and return semantics.
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: the first states purpose and alternative, the second lists possible outcomes. Every sentence is informative with no fluff, and key information is front-loaded.
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 simple tool, complete schema parameter descriptions, and annotations covering safety, the description is adequate. It explains behavior (blocking), outcomes (reply/permission/terminal/timeout), and next steps (respond_permission), making it complete for an agent to use 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 covers all 3 parameters with descriptions (100% coverage), so the baseline is 3. The description references the turn from cs_agent_send but adds no parameter-level detail 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 'Preferred blocking wait after cs_agent_send for one turn,' specifying the action (blocking wait), resource (message/turn), and relationship to send. It also distinguishes from cs_agent_wait_many, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Preferred blocking wait after cs_agent_send for one turn' and instructs to use cs_agent_wait_many for multiple turns after sending all independent turns. This provides direct when-to-use and alternative-selection guidance.
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:

[![cs-agent-mcp MCP server](https://glama.ai/mcp/servers/codestable/cs-agent-mcp/badges/card.svg)](https://glama.ai/mcp/servers/codestable/cs-agent-mcp)

Score Badge

Copy to your README.md:

[![cs-agent-mcp MCP server](https://glama.ai/mcp/servers/codestable/cs-agent-mcp/badges/score.svg)](https://glama.ai/mcp/servers/codestable/cs-agent-mcp)

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/codestable/cs-agent-mcp'

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