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

With annotations only covering safety/idempotency, the description adds substantial behavioral context the agent cannot get elsewhere: the shelf is read-only in MemoStem, expires after 90 days, requires account connection at 10 cards, and the workspace_token must be reused but never shown to the user. The 'read-only in MemoStem' phrasing describes the downstream shelf, not the tool call itself, so it does not conflict with readOnlyHint=false.

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?

Four sentences, front-loaded with the purpose before the conditional gate, credential rule, and shelf lifecycle facts. Every sentence carries distinct information, though density could be trimmed slightly without losing meaning.

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 tool with full annotations and an output schema (so return values need no explanation here), the description covers the trigger condition, credential handling, and shelf lifecycle well. The remaining hole is the undocumented provider/provenance/request_id parameters, which leaves the agent relying solely on raw JSON Schema types for four of five inputs.

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 description coverage is 0%, so the description carries the full burden, yet it only illuminates two of five parameters: bundles ('one to 10... bundles') and workspace_token (reuse it, never reveal it). provider, request_id (presumably an idempotency key), and the entire provenance object--including its required conversation_ref and the const-constrained type--are undocumented in both schema and description.

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 ('Store'), resource ('general-knowledge bundles'), scope ('one to 10'), and destination ('private temporary MemoStem guest shelf'), which cleanly separates it from the drafting/preview/validate siblings. It does not name any sibling explicitly, but the 'specifically selected, independently teachable' qualifier distinguishes it from draft-creation tools.

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 trigger: 'Call only after a direct request or clear acceptance of a specific proposal,' which is a real when-to-use gate. It never names an alternative tool (e.g., create_knowledge_bundle_drafts or validate_knowledge_bundle) as the preceding or substitute step, so the routing guidance is clear but incomplete.

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