Skip a card forever
skip_cardDon't learn at all: the word is not needed, the card will not come up in review, quizzes or conversations. For words the user already knows there is mark_known.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes |
skip_cardDon't learn at all: the word is not needed, the card will not come up in review, quizzes or conversations. For words the user already knows there is mark_known.
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds genuine behavioral context beyond that: the card is not deleted but suppressed across review, quizzes, and conversations, which is the practical effect of the destructive flag. It stops short of saying whether the suppression is reversible or how to undo it, which is the one remaining gap.
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, front-loaded with the core outcome and ending with the disambiguating alternative. No filler or repetition of the name/title.
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?
For a one-parameter destructive toggle, the description plus annotations cover outcome, irreversibility hint, and the sibling alternative, and no output schema exists to explain. The only omission is identifier semantics for card_id, which is minor but leaves the agent guessing at the one input it must supply.
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 0% and the single parameter (card_id) is only titled 'Card Id' with no type/format guidance. The description refers to 'the word' and 'the card' generically but never clarifies what identifier to pass. With low coverage, the description should compensate for the schema gap and does not.
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 action (skip a card, permanently) and spells out the exact consequence: the word will not appear in review, quizzes, or conversations. It also names the sibling it is distinct from (mark_known), so an agent can route between the two without opening either schema.
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?
Explicitly gives the selecting condition for the alternative: 'For words the user already knows there is mark_known.' That is a when-to-use-other rule, which is exactly what a routing agent needs.
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.