Codebase Context

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool creates persistent memories (implied by 'record'), requires explicit user triggers, handles one convention per memory (calling multiple times for lists), and has formatting constraints (5-10 words for memory, 1 sentence for reason). It doesn't mention rate limits, authentication needs, or error conditions, but covers the core operational behavior well.

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 well-structured with clear sections (trigger conditions, formatting rules, exclusions) and uses bullet points effectively. It's appropriately sized for the tool's complexity, though the 'HOW TO WRITE' section could be slightly more concise. Every sentence earns its place by providing essential guidance.

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 tool with no annotations and no output schema, the description provides good contextual completeness. It covers when to use the tool, how to format inputs, and what to exclude. The main gap is the lack of information about what happens after calling (e.g., confirmation message, error handling, or how memories are stored/retrieved), but given the tool's relatively simple purpose and good parameter documentation, this is adequate.

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 100%, so the schema already documents all four parameters with descriptions and enums. The description adds some semantic context by specifying 'memory: 5-10 words (the specific rule)' and 'reason: 1 sentence (why it matters)', which provides formatting guidance beyond the schema's 'concise' and 'why this matters' descriptions. However, it doesn't explain the 'type' or 'category' parameters beyond what the schema provides.

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: to record/remember something when explicitly requested by the user. It specifies the exact trigger conditions with concrete examples ('Remember this: [X]', 'Record this: [Y]'), distinguishing it from sibling tools like get_memory or search_codebase which retrieve rather than store information.

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 explicit usage guidelines: 'CALL IMMEDIATELY when user explicitly asks to remember/record something' and '⚠️ DO NOT call unless user explicitly requests it.' It also gives concrete user trigger examples and distinguishes when to use it (explicit requests) versus when not to (one-time features, code examples, essays).

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