confirm

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the side effect of incrementing a Bayesian confirmation count and explains the impact on future searches. It also clarifies the memory state this implies ('accurate'). However, it doesn't specify whether updating or correcting an inaccurate memory would be done via a different tool, which could be relevant context for the agent.

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 sentences, zero wasted words. Each sentence earns its place: what it does, what happens as a result, and when to use it. The description is immediately understandable and front-loaded with the primary action.

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 simulator with a single parameter and no output schema, the description is concise and effectively conveys the tool's purpose, behavior, and usage, saving the agent from needing to inspect the schema. It could be slightly improved by mentioning the limitations (e.g., no auth or rate limits) but these seem unnecessary for the tool's simple function.

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% for the single parameter 'capture_id', and the description adds the concept that confirming is for 'memories'. However, the description does not clarify what qualifies as a memory or how to reference it, relying on the schema's 'ID of the capture'. It adds a bit of context by linking the 'capture' concept but the link is implicit.

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 clearly states the tool's purpose with a specific verb ('Confirm'), resource ('memory'), and mechanism ('Increments the Bayesian confirmation count'). It distinguishes itself from sibling tools by focusing on the confirmation action, which is distinct from tools like 'recall', 'forget', or 'resolve'. The phrase 'raising its confidence score in future searches' adds functional clarity.

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 provides clear guidance on when to use the tool ('when a recalled memory proved helpful and correct'), but does not explicitly mention when not to use it or name alternatives. Sibling tools like 'correct', 'supersede', or 'forget' are logical alternatives when the memory is inaccurate, but this distinction is not explicitly stated. The usage context is implied rather than contrasted with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.