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

Annotations already disclose non-readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real context beyond that: the 500-item batch cap and the mutual-exclusion rule that associations[] must not be combined with top-level memory1_id/memory2_id/type/strength. It stops short of saying what happens on unknown memory IDs or directionality semantics beyond the examples.

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?

Front-loaded with the one-sentence purpose, then clearly headed sections for when-to-use, type semantics, and examples. The type list and examples are long but each earns its place; the three near-identical examples with full UUIDs are somewhat repetitive and could be trimmed to one pair plus one batch call.

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 14-parameter mutation tool with an output schema and annotations present, the description covers the remaining gaps: mode selection, batch limit, mutual exclusion, valid vs invalid relation types, and strength intuition. Return values need not be explained since an output schema exists, so nothing essential 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 coverage is 100%, so the baseline would be 3; the description earns an upgrade because the schema lists the type enum without per-value meaning, and the description defines all eleven authorable relationship types with examples (LEADS_TO = causal, INVALIDATED_BY = superseded, etc.). The worked examples also show strength values in context (0.9, 0.8).

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 and resource ('Create typed relationships between memories') and immediately names the value proposition (knowledge graph improving recall). It also distinguishes the two invocation shapes, single-pair vs batch via associations[], so an agent knows the tool's full surface without opening the schema.

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?

An explicit 'When to use' block gives four concrete triggering scenarios (after store_memory, bug fix vs feature, superseding decisions, pattern/example pairing). It also gives an explicit when-NOT: system relations such as SIMILAR_TO and DISCOVERED may show up in recall but are not valid inputs here, which prevents a plausible failure mode.

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?

Annotations already declare destructiveHint=true and idempotentHint=false, but the description goes well beyond them: Mode 2 deletes ALL memories matching ANY tag, matching is exact/case-insensitive, there is no dry-run, a single call can remove thousands, and the embedding goes with the memory. The only wrinkle is 'Mode 1 ... Idempotent' versus idempotentHint=false — it is reconciled by the explicit 'Mode 2 NOT idempotent in practice' sentence, so it is a scope nuance rather than a contradiction, though it demands careful reading.

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?

Front-loaded with the two-mode summary and scoped with bold headers, so an agent can stop reading after the first line if it already knows the mode. It runs long and repeats schema text (exact/case-insensitive matching, no dry-run appear twice), which is the only thing keeping it below a 5.

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?

Both parameters, their XOR relationship, defaults, and the destructive bulk hazard are covered, and an output schema exists so return values need not be described. For a two-parameter destructive tool, nothing an agent needs to call it safely 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 coverage is 100%, so the baseline is 3; the description earns above that by supplying a default ('Single (default)'), clarifying XOR selection between `memory_id` and `tags`, spelling out any-of/case-insensitive tag matching, and giving concrete call examples. It largely echoes the schema's own parameter descriptions rather than adding new syntax, which caps it at 4.

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 (delete a memory) and breaks it into two clearly labeled modes with the parameter that selects each. It also positions itself against the sibling `update_memory` as the preferred alternative, so an agent can distinguish it from `store_memory`/`recall_memory`/`update_memory` without opening any schema.

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?

Explicit 'When to use' bullets map each mode to concrete situations (incorrect info, duplicates, benchmark cleanup, deprecated tag namespaces), and it names alternatives: 'consider `update_memory` instead' and 'Verify with `recall_memory({ tags, exhaustive: true })` first'. When-not guidance ('use sparingly', 'no dry-run') is unambiguous.

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 annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is largely covered. The description still adds genuine operational detail: endpoint routing (GET /memory/{id}, GET /memory/by-tag), that mode 1 updates last_accessed, that ranked mode is server-clamped to ~50 and has no offset, that token budgets apply, and which parameter combinations are rejected. However, 'updates last_accessed' is a state mutation not reflected in readOnlyHint, and the description doesn't reconcile that tension or explain why the tool remains read-only — a small but real disclosure gap for a tool with 38 parameters.

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?

Structure is strong — modes are front-loaded and bolded, decision rules are bulleted, examples are labeled by mode — so an agent can scan to the relevant section fast. It is nonetheless long, and the five examples partly restate rules already stated in prose, which is defensible for a 38-param dispatcher but not maximally tight.

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 optional parameters, high enum count, a full output schema, and read-only annotations, the description supplies everything an agent needs to choose a mode and populate the right params: mode triggers, defaults, pagination behavior, rejected combinations, and worked examples. Return-value explanation is correctly delegated to the output schema rather than duplicated.

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%, so the baseline is 3, but the description goes well beyond per-parameter docs by explaining cross-parameter semantics: which param activates which mode, that memory_id causes all other params to be ignored, and that tag_match: 'prefix' plus tag_mode: 'all' are rejected in enumeration mode. That mode-dispatch logic is not expressible in the JSON schema and is the single most important thing to get right here. It stops short of 5 because many of the 38 secondary params (recency_bias, adaptive_floor, expansion_limit, etc.) are left entirely to the schema.

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 opening sentence names a specific verb and resource ('Recall memories from AutoMem') and immediately introduces the three-mode structure that defines the tool's identity. The mode descriptions (ID fetch, tag enumeration, ranked retrieval) make it trivially distinguishable from siblings like store_memory, update_memory, and delete_memory, which are all single-purpose mutations.

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?

It gives explicit when-to-use guidance per mode: a bulleted list of ranked-recall scenarios (conversation start, pre-decision checks, debugging, multi-hop questions) and a contrasting rule for enumeration ('when you need to know *how many* memories carry a tag'). It also states the key exclusion — ranked recall undercounts large tag sets, so use mode 2 for cleanup/audit — which is exactly the kind of routing guidance that prevents wrong-tool 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?

Beyond the annotations, the description discloses key side effects: supersede marks the old memory invalid, merges metadata, and creates an INVALIDATED_BY or EVOLVED_INTO relation. It also documents batch limitations, content-size summarization/rejection thresholds, and mode-specific constraints.

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 justified by a 16-parameter tool with three storage modes. Headers, bullets, and examples are front-loaded around mode choice, and the length is proportionate to 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 annotations, complete schema, nested objects, and output schema, the description covers the information needed to call the tool correctly: mode selection, supersede behavior, batch constraints, and size limits. No essential call-correctness detail appears 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?

Although schema coverage is 100%, the description adds substantial meaning: XOR-style mode selection, per-item batch restrictions, supersede side effects, content-size guidelines, and concrete examples. These details go materially beyond the schema field 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 states a specific verb and resource and clearly separates single, supersede, and batch storage modes. It does not explicitly name sibling tools such as recall_memory or update_memory, so sibling differentiation is left implicit.

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?

It provides concrete 'When to use' scenarios, including decisions, patterns, bug fixes, preferences, and bulk ingestion, and it explains when to choose batch versus single mode. It stops short of explicit when-not guidance or naming sibling alternatives for updates versus storage.

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=false, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the useful 'correct rather than duplicate' angle but doesn't say what happens if memory_id doesn't exist, whether omitted fields are preserved, or how content replacement interacts with history. Nothing contradicts 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 core purpose is front-loaded in the first sentence, and the 'When to use' list follows logically. The three example calls are helpful but occupy a third of the text and largely restate what the schema properties already say.

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 12 parameters, an output schema, and full annotations, the description needs to carry mostly intent and routing, which it does. The remaining gap is behavioral edge cases (missing memory_id, partial-update semantics), which the rich schema partially covers.

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%, so every one of the 12 parameters is already documented, and the schema even states replace-vs-merge semantics for tags, content, and metadata. The description names only four fields and its examples show invocation shape rather than adding meaning beyond the schema.

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 and resource: updating an existing memory's content, tags, importance, or metadata. It also explicitly distinguishes itself from the sibling store_memory by saying to use this 'rather than storing duplicates,' so an agent can route correctly without opening either schema.

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' block gives four concrete situations (correction, missing tags, importance adjustment, post-hoc metadata) and rules out the duplicate-store path. It stops short of naming delete_memory or store_memory explicitly as the alternative to pick for other cases, leaving a small gap.

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