rappi_logoutLog out from Rappi by clearing the local token file. Requires explicit user intent before performing the action.
Clears the local token file. Requires explicit_user_intent. Not gated by RAPPI_ALLOW_MUTATIONS.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | markdown | |
| explicit_user_intent | No | Must be true after the user explicitly asked for this write. |
Changes observed during successful MCP inspections.
v0.1.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false; the description confirms the destructive scope by naming the local token file as the target. It adds genuine value beyond annotations by disclosing that the tool bypasses RAPPI_ALLOW_MUTATIONS, which signals the agent that explicit_user_intent is the only safeguard. No contradiction with annotations exists.
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 with no filler; the core action is front-loaded and the gating caveat is disclosed last. Every sentence earns its place, though the same intent caveat appears both in the description and the schema, a slight redundancy.
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 simple logout tool, the description covers the action, the safety precondition, and the gating exception. The schema documents both parameters (response_format via enum, explicit_user_intent via description), and annotations carry the destructive/idempotent profile. Nothing an agent needs to invoke this correctly is missing.
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 coverage is 50%, and the description compensates partly by connecting 'Requires explicit_user_intent' to the boolean flag. However, response_format receives no description-level treatment beyond its enum in the schema, and the intent requirement largely echoes the schema's own parameter description. Marginal added meaning over the schema.
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 ('Clears'), a specific resource ('the local token file'), and the scope of the effect. Since no sibling tool performs logout, it is trivially distinguishable from all 40+ siblings without ambiguity.
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 conveys the key precondition ('Requires explicit_user_intent') and the unusual operational context ('Not gated by RAPPI_ALLOW_MUTATIONS'), telling the agent when it may run and that the normal mutation gate does not protect the user. It does not state explicit when-not-to-use cases, but no alternative logout sibling exists, so exclusion guidance is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.