Clanker

by kckylechen1

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.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: cancel, dispatch (convenience wrapper), dispatch_start (initiate), list, prompt (existing session), status, wait. No overlap despite some convenience aliasing.
Naming Consistency5/5
All tool names follow the consistent 'clanker_verb' pattern in snake_case. Verbs are descriptive and predictably relate to actions (cancel, dispatch, list, prompt, status, wait).
Tool Count5/5
7 tools cover the full session management lifecycle without being excessive. Each tool addresses a necessary operation, from starting to polling to cancellation.
Completeness4/5
Core CRUD-like operations are covered: start a turn, wait, check status, list sessions, cancel. Missing an explicit 'delete or close session' tool, but cancel may suffice. Slight gap for cleanup.
Average 4.4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds valuable behavioral context: non-blocking nature, stall detection field (suspected_stall), and that it returns current plan and tool_calls. No contradictions.
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, no unnecessary words. First sentence clearly lists return fields. Second sentence clarifies behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, description is complete: explains return structure, non-blocking nature, stall detection. Could mention it is a lightweight check without side effects, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'id' with schema description 'Run id'. Schema coverage is 100%, so description does not need to add much. The tool description does not elaborate on the parameter beyond what schema provides, which is acceptable but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states what the tool does: returns a specific set of fields including status, plan, tool_calls, last_event_age_ms, suspected_stall. Distinguishes from sibling like clanker_wait by explicitly saying 'Does not wait.'
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?
Implied usage: use for quick status check without waiting. But no explicit when-to-use/when-not-to-use or alternative references (e.g., 'Use clanker_wait to block until completion'). Only 'Does not wait' hints at distinction.
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 indicate destructiveHint=true (destructive) and readOnlyHint=false (write operation). The description adds context about the return value ({id}), polling via clanker_wait, and specific error scenarios. This provides useful behavioral details beyond what annotations convey, though it does not detail side effects on session state.
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 fluff. The first sentence covers purpose and output, the second covers error conditions. Information is front-loaded and every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters with full schema coverage, clear annotations, and no output schema, the description is sufficient. It explains the return value ({id}), the polling mechanism (clanker_wait), and error conditions, providing all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters ('id' and 'prompt') adequately. The description does not add any additional semantic detail beyond the schema. According to the rubric, when coverage is high, baseline is 3, and no extra value is added.
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 states the tool's purpose: 'Start a new prompt turn on an already-open session'. The phrasing 'persistent-session reuse' implies continuation of an existing session, which helps distinguish it from tools like clanker_dispatch or clanker_dispatch_start that likely initiate new sessions. However, it does not explicitly differentiate from all siblings.
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 specifies the context for use ('on an already-open session') and mentions error conditions ('session reaped/closed or a turn already running'), which helps the agent decide when to invoke this tool. It also references clanker_wait for polling. Missing explicit when-not-to-use guidance, but the error conditions imply prerequisites.
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 indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying it includes live sessions only and excludes reaped/closed ones, plus showing the output structure.
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?
One sentence plus compact field list; no unnecessary text. Front-loaded with purpose and structured output.
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 zero-parameter list tool, the description covers what is returned and what is omitted. Could optionally include ordering or limit, but not essential.
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?
No parameters are defined. Per guidelines, 0 parameters yields a baseline of 4. The description appropriately avoids parameter detail since none exist.
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 lists active Clanker sessions with a specific set of fields. It distinguishes from sibling tools (e.g., clanker_cancel, clanker_status) by focusing on a collective overview of live sessions.
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?
No explicit guidance on when to use this tool vs alternatives. While it's obvious for listing all active sessions, there is no mention of when to prefer this over clanker_status or other siblings.
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?
The description adds behavioral details beyond annotations: it explains the return format, the idempotent behavior ('No-op if the session is idle'), and the backend call. Annotations already indicate destructive and idempotent hints, and the description aligns without 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 convey all necessary information: the action, return, and edge case. No waste, front-loaded with key 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?
Given the simple parameter, full schema coverage, and good annotations, the description is nearly complete. It could possibly mention the source of the run id or prerequisites, but it's adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'id' as 'Run id.' The description does not add any further meaning or usage details beyond what the schema 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 action ('Send ACP session/cancel'), the resource ('Clanker backend'), and the effect ('Returns {id, status}'). The title specifies 'Cancel a Clanker's in-flight turn,' making the tool's purpose distinct from siblings.
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 implicitly tells when to use by stating it cancels an in-flight turn and is a no-op if idle. However, it does not explicitly mention alternatives or when not to use, though the context is clear enough.
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 annotations (destructiveHint: true, etc.), the description adds that this tool blocks until the turn is terminal, and warns about potential MCP request timeouts for long tasks. It also specifies the return structure (WaitResult with fields status, final_message, etc.), which is not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first explains the purpose and behavior, the second provides a usage guideline. It is concise, front-loaded, and contains no 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?
Given the tool's complexity (blocking, 7 parameters, no output schema), the description explains the return structure and timeout concerns. It references sibling tools for long tasks. Missing error handling details, but overall adequate for a convenience wrapper.
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 descriptions for all parameters, so baseline is 3. The description does not add additional parameter-level detail beyond the schema, but it provides context on the return structure (WaitResult) which compensates slightly for the lack of output 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 title and description clearly state the tool dispatches a Clanker and blocks until completion. It explicitly distinguishes itself from sibling tools like clanker_dispatch_start (which does not block) by describing it as a convenience path combining start and wait.
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 advises 'For long tasks prefer clanker_dispatch_start + clanker_wait' to avoid MCP request timeouts, providing clear when-to-use and when-not-to-use guidance with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context: it's non-blocking, returns an id immediately, and explains error handling ('setup errors fail here; runtime errors surface via clanker_wait'). This goes beyond annotations without 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 with no wasted words. The key action is front-loaded, and crucial guidance (polling, error separation) is included concisely. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return value ({id}), the polling mechanism (clanker_wait), and error differentiation. While there is no output schema, the return value is stated. It could detail cancellation (via clanker_cancel) or more error scenarios, but given the tool's moderate complexity, it is reasonably 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 each parameter is described in the schema. The description adds meaning by explaining that errors related to 'lane' and 'worktree' parameters (unknown backend, worktree creation) surface immediately, providing error-handling context beyond the schema 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 action: 'Spawn/handshake a Clanker and start a prompt turn, returning {id} immediately.' It uses specific verbs ('start', 'spawn') and resource ('Clanker'), and differentiates from siblings like clanker_wait by highlighting the non-blocking nature and immediate return.
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 tells the user to 'Poll progress with clanker_wait(id)' and distinguishes setup errors from runtime errors, guiding the agent to use this tool for initiating tasks and clanker_wait for monitoring. It provides clear when-to-use and alternatives.
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?
The description discloses many behavioral details beyond the annotations: quiet mode debouncing, what events trigger early wake (plan/status change, tool error, suspected stall, terminal state), and what trivial chatter does not. It also describes the return structure and digest contents. No contradiction with annotations (readOnlyHint, openWorldHint).
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 moderately concise; it is long but each sentence serves a purpose. It front-loads the core functionality and then details behavior. The quiet mode explanation could be slightly tightened, but it is well-structured.
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?
No output schema exists, so the description must cover return values. It does: 'Returns {status, digest, plan_summary, last_event_age_ms, suspected_stall}' and terminal fields. It also explains digest content and quiet mode. Given the tool's complexity and lack of output schema, this is fully adequate.
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?
Schema coverage is 100%, yet the description adds significant meaning: timeout_ms default and cap, quiet mode default and effect, and the id's origin ('from clanker_dispatch_start / clanker_dispatch'). This enhances the agent's understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Wait up to timeout_ms for new events or completion.' It uses specific verbs ('Wait', 'long-poll') and specifies the resource ('Clanker run'). The description distinguishes it from siblings by detailing the long-polling behavior and return data, which is not available in other tools like clanker_status.
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 usage guidelines by explaining when to use the tool (to wait for events/completion) and how the quiet mode affects behavior. It explicitly states that 'callers no longer need to repoll tightly' and contrasts quiet against the old any-event wake-up, offering clear context for use.
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:

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

Score Badge

Copy to your README.md:

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

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/kckylechen1/ClankerHouse'

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