survey_skipSkips the short in-product survey Local MCP showed the user, for now — use this when the user doesn't want to answer right now. They won't be asked again this session.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Ignored; kept for older clients. |
| Name | Required | Description | Default |
|---|---|---|---|
| ok | No | ||
| message | No | ||
| preview | No |
Changes observed during successful MCP inspections.
Input schema / properties / confirm / descriptionPrevious value: -"Must be true to skip. Without it, returns a preview and changes nothing."New value: +"Ignored; kept for older clients."Input schema / properties / confirmAdded value: +{
+ "description": "Must be true to skip. Without it, returns a preview and changes nothing.",
+ "type": "boolean"
+}Output schema / properties / previewAdded value: +{
+ "type": "boolean"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations flag destructiveHint=true and openWorldHint=true, and the description supplies the key context that resolves the apparent severity: the skip is scoped, 'They won't be asked again this session.' This clarifies the blast radius of a destructive-flagged call, though it doesn't say whether the skip is reversible or reported anywhere.
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?
Two short sentences, zero redundancy, with the action and the usage condition front-loaded before the session-scoping consequence.
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?
An output schema exists, so return values needn't be explained, and the description covers action, trigger, and persistence scope. What's missing is only minor: no mention of preconditions (that a survey must be pending) or what the agent should tell the user afterward.
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?
Schema description coverage is 100% and the single parameter ('confirm') is documented in-schema as 'Ignored; kept for older clients.' The description adds nothing about parameters, which is acceptable since the schema fully covers it, but no bonus is earned.
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?
States a specific verb ('skips') and resource ('the short in-product survey Local MCP showed the user') with clear temporal scope ('for now'). It does not explicitly name the sibling survey_respond, so an agent must infer the pairing, but the purpose itself is unambiguous.
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?
Gives a concrete trigger condition: 'use this when the user doesn't want to answer right now.' That effectively routes the agent away from survey_respond, though it never names that alternative or states any precondition such as a survey being active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.