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

Annotations already indicate idempotentHint=true, and the description reinforces this by explaining 'Re-ingesting the same session_id updates it instead of duplicating.' It adds meaningful behavioral context beyond annotations: permanent storage, searchability, knowledge graph appearance, and the requirement to ingest verbatim full answers. The exclusions also disclose exactly what will NOT be stored. No contradiction with annotations.

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?

The description is a single dense paragraph that leads with the core purpose, then covers when to use, exclusions, idempotency, and splitting. Every sentence adds necessary guidance for a tool with many caveats. While it is longer than minimal, it remains efficient and well-organized, just slightly verbose for a 10/10.

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 write-only tool with no output schema, the description fully addresses what the tool does, when to use it, what to exclude, how to handle idempotent updates, and how to manage long conversations. The combination of schema (100% parameter descriptions), annotations (idempotentHint), and description gives an agent everything needed for correct invocation.

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 clear descriptions for title, turns, and session_id. The description adds value by clarifying 'your full answers, verbatim' (emphasizing the completeness of assistant turns) and by advising to 'Split very long conversations across calls,' which informs the agent how to use the turns/session_id combination effectively. This goes beyond the baseline schema descriptions.

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 uses a specific verb+resource ('Ingest a conversation ... into the user’s permanent memory') and clearly states what is ingested (user messages and full assistant answers verbatim) and the resulting effects (searchable, knowledge graph). It distinguishes itself from sibling tools like cortex_recall and cortex_remember by focusing on permanent conversation storage and the exclusion of non-knowledge content.

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 gives explicit when-to-use guidance ('Use it after an exchange where you gave a substantive answer') and a thorough when-not-to-use exclusion list (cannot-answer replies, tool outputs, hidden reasoning, connect links, credentials). It does not explicitly name an alternative sibling tool, but the context is strong enough to make appropriate selection clear.

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