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

Annotations carry the safety profile (readOnlyHint=false, destructiveHint=false, no contradiction). The description adds valuable behavioral context beyond the annotations: storage is cheap so more detail retrieves better, recall returns only what earlier sessions stored, and the caller composes summary/context from the conversation rather than from the user. This helps the agent reason about side effects and persistence without contradicting the structured data.

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?

Well-structured with clear section headers ('WHAT IS WORTH RECORDING', 'FIELDS') that make scanning easy. The description is long but every section earns its place — the field documentation adds genuine guidance rather than padding. Slightly more verbose than strictly necessary, but the structure mitigates this.

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 9-parameter memory-persistence tool, the description covers the core purpose, usage criteria, and field semantics thoroughly, and an output schema exists to handle return values. The optional metadata fields are not documented, but they are self-explanatory. The description gives the agent everything needed to record a session correctly.

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?

With 56% schema coverage, the description compensates meaningfully. It documents summary (50-75 tokens, one tight paragraph), user_query (verbatim, no truncation, matched against the user's own words), context (2000-8000 tokens, technical details untruncated), and conversation_id (must match recall_context). This goes beyond the schema by explaining the why behind each field. Undocumented params (persona, billable, artifact_url, client_project, company_client) are self-descriptive metadata fields, so the gap is acceptable.

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 pair — 'Records the outcome of a session to the user's NC memory, so that later sessions can recall it.' This clearly distinguishes it from sibling readers like recall_context and search_memories, and the description explicitly contrasts it: 'Recall returns what earlier sessions stored and nothing else.' The agent can immediately tell what this tool is for and what it is not.

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?

Provides explicit when-to-use criteria under 'WHAT IS WORTH RECORDING' — a session that produced something a later session would reconstruct (decision+reasoning, fix+why, constraint, state change), and explicitly states when NOT to use it: 'A session that only answered a self-contained question leaves nothing to recall.' This is direct usage guidance with a clear exclusion rule.

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