Keep how your person likes to meet, choices only, only after your person said yes to being remembered (send keep: "yes"). Give them the private link it returns.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Optional: weekdays or weekends. | |
| keep | Yes | Send yes only after your person said yes to being remembered. | |
| time | No | Optional: daytime or evenings. | |
| level | No | Optional: beginner or experienced. |
Changes observed during successful MCP inspections.
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / keep / descriptionPrevious value: -"Send yes only after your person said yes to being remembered. Without it nothing is kept."New value: +"Send yes only after your person said yes to being remembered."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only, non-destructive, open-world write, and the description adds real behavior beyond them: a consent requirement before writing, that values are constrained to preset choices, and that the tool returns a private link the agent must hand to the user.
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?
A single dense sentence with zero filler: purpose, consent gate, value constraint, and return-handling instruction in that order. Nothing needs trimming.
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?
Covers the consent gate and the return value (needed since there is no output schema), which are the two things an agent could otherwise get wrong. Silent on idempotency/overwrite behavior if the person is remembered twice, a minor remaining gap for a 4-param write tool.
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 100% with all four parameters documented as enums, so the schema already carries the semantics. 'Choices only' usefully reinforces that no free text should be sent, but the rest of the description only restates the keep: "yes" gate that the schema declares.
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+resource: keep (persist) how a person likes to meet, restricted to the enumerated choices. It is distinguishable from the sibling fathom_forget by the persistence direction, though the description never names that or any other sibling explicitly.
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 an explicit precondition — only after the person has said yes to being remembered, signalled via keep: "yes" — which is exactly the gate an agent needs before invoking. It does not mention the inverse case (use fathom_forget to remove) or what to do if the person declines.
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.