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

Annotations indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false, which describe the tool as non-destructive and idempotent. The description adds that batch mode supports up to 500 associations, lists valid authorable relationship types, and notes that internal relation types appear in recall but are not valid inputs. This provides rich behavioral context beyond 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 well-structured: overview, when-to-use, relationship types list, examples. It uses bullet points for readability and avoids unnecessary repetition. Every sentence serves a purpose, and the length is appropriate for the tool's complexity.

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?

Given the tool's complexity (14 parameters, batch mode, many relationship types), the description covers all key aspects: purpose, usage scenarios, relationship type explanations, batch mode limits, and examples. The presence of an output schema means return values don't need to be described. The description is fully adequate for an agent to select and invoke the tool 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?

Schema coverage is 100% (all parameters have descriptions in the schema). The description adds value by explaining which parameters are relation-specific (e.g., reason for PREFERS_OVER, confidence for EXEMPLIFIES) and by listing relationship types with meanings. The examples also illustrate parameter usage. Overall, the description enhances understanding beyond the 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 clearly states the tool 'creates typed relationships between memories' and explains it improves recall via a knowledge graph. This distinguishes it from sibling tools like store_memory (store a single memory) and recall_memory (retrieve memories).

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 includes a 'When to use' section with specific scenarios (e.g., after storing a new memory, when a bug fix relates to a feature). It also distinguishes between single-pair and batch mode, and clarifies which relationship types are not valid inputs. However, it does not explicitly state when not to use the tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false. Description adds value by specifying the components checked (FalkorDB graph + Qdrant vectors) and the service context (AutoMem). No contradictions.

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?

Extremely concise: one-line purpose, bulleted use cases, and example. Every sentence adds value. Front-loaded with key information.

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?

Given zero parameters and the presence of an output schema, the description is complete. It covers purpose, usage guidance, and provides an example. No gaps.

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?

No parameters (0 params, baseline 4). Schema coverage is 100%, so description does not need to compensate. The description effectively explains the tool's purpose without needing parameter details.

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?

Description clearly states verb+resource: 'check the health status of the AutoMem service and its connected databases'. Differentiates from sibling tools like store_memory and recall_memory which are CRUD operations.

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 scenarios: before a session, when memory operations fail, and to check statistics. Does not mention when not to use or alternatives, but sibling differentiation makes it clear.

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

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

Disclosures beyond annotations: idempotent for single mode, not idempotent for bulk, exact case-insensitive tag matching, no dry-run, potential for mass deletion. No contradiction with annotations indicating destructive and non-idempotent behavior.

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 headings, bullet points, and examples. Information is presented efficiently and front-loaded with core action, making it easy to parse.

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?

With output schema present and parameters fully described, the description covers all essential aspects: modes, usage context, safety warnings, and verification steps. No important gaps remain.

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%, but description adds XOR relationship, mode differentiation, exact tag matching details, and no-dry-run warning. This significantly enhances understanding beyond 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 clearly states the tool deletes memories by ID or bulk by tag, specifying two modes with distinct behaviors. It differentiates from sibling tools like update_memory, providing a precise action and resource.

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?

Explicitly advises to use sparingly and consider update_memory instead, and provides specific scenarios for each mode, including verification steps for bulk deletion. This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds valuable behavioral detail beyond that: ID fetch routes to GET /memory/{id} and updates last_accessed, enumeration uses paginated exact-match listing, ranked mode clamps server-side to ~50 results, and mode-specific options are rejected. There is no contradiction with the 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 long but appropriately structured for a tool with 38 parameters and three modes: it front-loads the mode-selection rule, uses clear headers, gives explicit when-to-use bullets, and ends with examples. Minor redundancy exists, such as repeating the cleanup/audit rationale in both Mode 2 and the usage section, but the overall organization is efficient for the complexity.

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?

Given 38 parameters, a rich schema, and an output schema, the description covers the decision space comprehensively: it explains all three modes, which params are ignored or rejected, pagination metadata, output format options, and when each mode is appropriate. The examples cover representative calls for each mode, and nothing critical for correct invocation is missing.

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 baseline is 3; the description still adds value by explaining how parameters select modes, how limit behaves differently in enumeration vs ranked mode, and by showing realistic parameter combinations in examples. It does not need to restate every schema field, and the mode-selection semantics go beyond what the schema alone conveys.

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 recalls memories from AutoMem and immediately differentiates three distinct modes based on which parameters are passed. It names each mode, the route it uses, and the outcome, and provides concrete examples for every mode, so an agent cannot confuse this with sibling tools like store_memory or delete_memory.

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: ranked retrieval for conversation start, decision-making, debugging, and multi-hop reasoning; tag enumeration when the agent needs exact counts or cleanup/audit walks. It also states exclusions such as 'NOT ranked retrieval' and which parameter combinations are rejected, leaving no ambiguity about mode selection.

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

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

The description reveals substantial non-obvious behavior: supersede invalidates the old memory, sets t_invalid=now, merges metadata, and links old-to-new via INVALIDATED_BY/EVOLVED_INTO. It also discloses size limits, auto-summarization over 500 characters, rejection over 2000, and batch-mode field exclusions—all beyond what annotations provide.

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 long but earned: it is organized into modes, size guidelines, when-to-use, and examples, making it scannable despite its length. The most important distinction (single vs batch) is front-loaded, and every section adds reusable decision value.

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?

Given a 16-parameter tool with nested objects, three behavioral modes, and multiple constraints, the description is remarkably complete. It covers entry points, per-parameter limitations, workflow patterns, content quality guidance, and representative examples. The presence of an output schema reduces the need to document return values.

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?

Although schema coverage is 100%, the description adds meaning the schema alone does not convey: mutual exclusivity of content vs memories is explained with mode-based grouping, content size targets are given, supersede parameter behavior is clarified, and three realistic examples show how parameters combine.

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 verb 'store' plus 'memory' and the explicit description of two operating modes (single and batch) make the purpose unmistakable. The supersede/correct mode is also described with concrete behavior, distinguishing it from a plain append operation even without naming siblings.

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?

A dedicated 'When to use' section lists concrete scenarios, and batch mode is specifically recommended for bulk ingestion. However, it never explicitly contrasts this tool with update_memory or delete_memory, so the guidance is clear but lacks exclusions/alternatives.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, which the description does not contradict. The description adds context about 'correct or enhance' but does not detail update semantics like overwriting vs merging (e.g., metadata merges per schema). Since annotations cover the core behavioral traits, the description provides moderate added value.

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 a clear header, a bulleted 'When to use' list, and examples. It is concise (5 sentences plus examples) and front-loaded. Slightly more could be trimmed but overall efficient.

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?

Given the tool has 12 parameters (all documented in schema), an output schema exists, and annotations are present, the description provides sufficient context for the main purpose and use cases. It lacks error behavior details but these are not critical given the schema coverage.

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 baseline is 3. The description does not add additional meaning beyond the schema; it only groups parameters in the first sentence. Examples illustrate some parameters but no new semantics.

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 verb 'Update' and the resource 'memory', and lists the updateable fields (content, tags, importance, metadata). It distinguishes from the sibling tool 'store_memory' by advising against storing duplicates.

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 'When to use' section provides four explicit use cases (correct inaccuracies, add tags, adjust importance, add metadata) and implicitly advises against using store_memory for updates. However, it does not mention when not to use this tool (e.g., if memory should be deleted entirely) or prerequisites (e.g., memory must exist).

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