Close a workspace and cancel its active calls without undoing changes or stopping separately supervised jobs. Repeating close is harmless.
Close this workspace and cancel its active calls. Does not undo changes or stop separately supervised jobs. Repeating close is harmless.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, yet the description says the tool 'cancels active calls' and 'closes' the workspace, which are side-effecting operations. This directly contradicts the readOnlyHint annotation, making the behavioral information unreliable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences that front-load the action, then give caveats and idempotency behavior. Every sentence earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main operation and some behavioral caveats, but the contradiction with readOnlyHint leaves the agent uncertain about actual side effects. It also omits what happens on success or whether any confirmation/return value is produced, which matters given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the workspace_id parameter at all, and schema description coverage is 0%. For a single self-explanatory parameter the schema provides the name and type, but the description adds no guidance on how to obtain or format the value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Close' with a clear resource 'workspace', and adds what the action involves ('cancel its active calls'). It is immediately distinguishable from the sibling workspace_open, which is the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for closing the current workspace and notes what it does not do (undo changes, stop separately supervised jobs), but it never explicitly states when to use this tool versus alternatives like workspace_open. The guidance is limited to implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.