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

With no annotations provided, the description carries the full behavioral disclosure burden. It meaningfully discloses that the returned context is 'the backend's own injection format' and should be treated as opaque text, and it advises calling only once. This is valuable behavioral context beyond what the schema provides, though it does not mention side effects, errors, or auth requirements.

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 compact and front-loaded: the main action in the first sentence, usage timing in the second, and the critical behavioral caveat in the third. Every sentence earns its place with no redundancy.

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?

The description covers the essential operational details: when to call, what the result is, and how to handle it. An output schema exists to document return values. The only minor gap is lack of guidance on what happens when there is no memory or how this relates to sibling memory tools.

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 optional parameters. The description adds no further parameter-specific meaning, which keeps this at the baseline score of 3.

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 ('Load the user's memory') and defines the output as 'text ready to put in your context.' The additional note about the backend's injection format and prepending it to the conversation clearly separates this from sibling tools like memory_search or memory_get, which imply structured retrieval.

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 clear when-to-use guidance: 'Call this once near the start of a task.' It also explains how to use the result ('prepend it to the conversation rather than parsing it'). However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It states 'Delete' but doesn't mention irreversibility, potential side effects, permissions required, or the behavior when the fact_id doesn't exist. The optional user_id and agent_name parameters are not explained in terms of their effect on deletion scope.

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 extremely concise, with two short sentences that front-load the core purpose and usage. Every word serves a purpose, with no redundancy or filler.

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 simple delete-by-id tool, the description covers the basic usage but lacks important context such as irreversibility, error handling, or scope implications of the optional parameters. Given the destructive nature and lack of annotations, more detail would be appropriate.

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 each parameter is already documented. The description adds a helpful reference for fact_id ('from `memory_search`'), but the optional parameters' semantics are left to the schema. Overall, it provides marginal added value over 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 description clearly states the action (delete a single fact) and the resource (by id), making the tool's purpose unambiguous. It also distinguishes it from update and search siblings by emphasizing deletion of a specific fact.

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 a clear trigger: 'Use when the user says a stored fact is wrong or no longer applies.' This gives direct guidance on when to invoke the tool, though it doesn't explicitly mention alternatives or when not to use it.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the operation is forced and time-bounded, but doesn't state whether it modifies persistent state, what happens if the timeout is exceeded, or whether it is safe to call repeatedly. The use case hints at a write operation but doesn't fully disclose side effects.

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?

Two sentences with zero waste. The action is front-loaded in the first sentence, and the second sentence provides practical context. Every word earns its place.

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 simple tool with one optional parameter and an output schema, the description adequately covers purpose, usage timing, and the timeout concept. Given no annotations, it could mention that this is a write/mutation operation more explicitly, but the picture is largely complete for an agent to call it 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% for the single parameter (timeout), so baseline is 3. The description's reference to a 'time budget' loosely maps to the parameter, but it adds no new semantic detail beyond what the schema already 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?

States a specific verb and resource ('Force pending memory extractions to run now'), which clearly distinguishes it from sibling tools like memory_get, memory_search, and memory_remember. The action is unambiguous and the name 'flush' is reinforced by the description.

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 concrete use cases ('before shutting down' and 'when a client wants the memory written before it reports success') that tell an agent when to invoke it. It doesn't explicitly mention when not to use it, but the two scenarios are clear and cover the main need.

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?

With no annotations provided, the description fully carries the behavioral disclosure burden. It clearly warns that the operation is destructive and irreversible, and discloses the important side effect that pending extractions for the same scope are cancelled, preventing queued updates from resurrecting the memory.

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 compact and front-loaded: the core action first, followed by critical warningslorantine side effects, then usage guidance. Every sentence earns its place with no filler.

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 destructive tool with no annotationsce, this description is remarkably complete. It covers what is erased, irreversibility, cancellation of pending extractions, scope nuance, and the alternative tool. The existence of an output schema means return-value documentation is not the description's job.

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 adds framing around scoping ('for one agent bucket') but the parameter-specific behaviors, such as preserving user-level summaries when agent_name is given, are already present in the schema, so the description does not add substantial extra meaning.

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 opens with a specific verb and resource: 'Erase stored memory for a user (or for one agent bucket).' It clearly distinguishes itself from siblings like memory_delete_fact and memory_flush by stating scope and effect.

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 explicitly says when to use it ('when the user asks to be forgotten') and when not to ('not to tidy up individual facts'), and names the exact alternative tool (`memory_delete_fact`). This removes all ambiguity about 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'everything (summaries plus the full fact list)' and is intended for inspection/export/debugging, which implies a heavier payload. It does not explicitly state it is read-only or mention performance implications, but given the tool name and the intended use cases, this is a minor gap.

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 two sentences with zero waste. The first sentence states the purpose, the second gives usage guidance. Information is front-loaded and efficiently organized.

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?

An output schema is present, so return format is covered. Parameters are fully documented. The description covers purpose and usage clearly. Minor missing details like error handling or behavior when no memory exists are not critical given the output schema and simple tool nature.

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% – both parameters (user_id, agent_name) have descriptions. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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 ('return') and resource ('complete stored memory document for a user'), and explicitly distinguishes it from siblings by naming memory_search and memory_context as alternatives. An agent can immediately understand what it does and how it differs.

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 explicitly states when to use the tool ('inspection, export or debugging') and when not to ('normal use'), and names the preferred alternatives (memory_search, memory_context). This leaves no ambiguity about 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does well by revealing the duplicate-detection behavior and the `status="duplicate"` return value, which is not visible in the schema. It could go further by noting whether the tool overwrites existing facts or how it handles conflicting facts, but the duplicate behavior is a meaningful disclosure beyond the structured fields.

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 compact and front-loaded: the core action is in the first sentence, followed by clear usage guidance and a behavioral note. Every sentence earns its place, and the duplicate warning is placed at the end where it reinforces the usage rule without cluttering the main purpose.

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 no annotations, the description covers the essential decision boundary (when to use, when not to use) and a key behavioral outcome (duplicate detection). The output schema exists, so return values need not be explained. It is slightly incomplete in that it doesn't mention whether the fact is upserted or how category/confidence defaults behave, but the schema covers those defaults and the description is otherwise sufficient 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 description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds a useful example ('prefers uv over pip') and clarifies the intended semantics of 'content' as a durable fact, but it does not need to add much more because the schema is complete. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Store one durable fact about the user.' It clearly distinguishes this from siblings like memory_get, memory_search, and memory_remember_conversation by emphasizing durable, user-stated facts rather than transient or conversational details. The scope is precise and immediately actionable.

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 explicitly states when to use the tool ('when the user states a preference, corrects you, or shares context worth carrying into future sessions') and when not to use it ('Do NOT use it for transient details of the current task'). It also warns against re-saving duplicates, which is a clear exclusion that helps an agent avoid redundant calls.

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?

No annotations are provided, so the description carries the full burden. It discloses that this is a write path, that extraction is delegated to a backend LLM, and that a missing LLM config causes an error rather than silently storing nothing. This is meaningful behavioral context beyond the schema.

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?

Three short sentences with no wasted words. The core action is front-loaded, the second sentence clarifies the design intent, and the third covers the prerequisite and failure mode. It avoids restating schema fields.

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 no annotations and an output schema, the description covers the essential context: what the tool does, when to use it, and what happens if the server lacks an LLM. Minor gaps like the exact write effect or return shape are acceptable because the schema already documents parameters and output.

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 structured schema already documents all parameters thoroughly. The description adds no per-parameter meaning beyond the schema, but it doesn't need to given the high coverage.

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 opens with a specific verb and resource: handing a conversation to the backend for automatic fact extraction. It also distinguishes itself from the fact-by-fact manual path, which clearly separates it from the sibling memory_remember tool.

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 clearly explains when to use this tool: when you want a hands-off, automatic extraction path rather than deciding fact-by-fact what to save. It also flags the LLM prerequisite and the resulting error behavior, though it does not explicitly name the alternative tool or list cases where manual saving is preferable.

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?

No annotations are present, so the description carries the behavioral burden. It discloses useful search behavior: keyword matching, conditional ranked matching when an index exists, and returns including category and confidence. It doesn't explicitly say the operation is read-only, but 'Search' strongly implies non-mutation, and the matching behavior is well described.

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?

Three short sentences front-load the core purpose, then provide usage timing, then explain matching behavior. Every sentence adds distinct value with no filler or repetition of schema details. The structure makes the tool easy to scan and act on.

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 an output schema present and 100% schema coverage, the description doesn't need to restate return structures. It supplies the key missing context: when to call it and how matching works. It could more explicitly route to sibling tools like memory_get or memory_context, but it is otherwise complete for a search tool.

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 five parameters. The description adds mild nuance to 'query' as a natural-language search and references category/confidence in results, but doesn't systematically enrich parameter meaning beyond the schema. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Search long-term memory for facts matching a natural-language query.' It clearly distinguishes this from the sibling memory tools by emphasizing natural-language search over retrieval, remembering, updating, or deleting. The 'best matches' framing further clarifies that this is a search-and-rank operation.

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 an explicit trigger condition: 'Use this before asking the user to repeat themselves.' This is concrete and actionable. It doesn't name alternative sibling tools or state when not to use it, but the guidance is clear enough for most agent decisions.

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?

With no annotations, the description must carry the safety profile. 'Report' and 'health' clearly frame this as a read-only inspection tool, and it adds context about what is inspected. It does not explicitly state 'no side effects' or address permissions, but nothing suggests mutation and the framing is sufficiently transparent for a status tool.

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?

Two tight sentences: the first states the core purpose and the second provides actionable use-cases. Every sentence earns its place with no redundant wording or restatement of the title.

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 read-only status reporting tool with two optional parameters and an output schema, the description covers what the tool does, the exact situations to call it, and enough context about defaults. The output schema covers return details, 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 0% and the description never names user_id or agent_name or explains how they filter/select the status returned. It only hints at identity through 'which identity the defaults resolve to,' which is insufficient to compensate for the complete lack of parameter documentation.

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 opens with a specific verb and resource: 'Report the memory backend's configuration and health.' It then enumerates concrete sub-purposes (model configured, storage location, identity defaults), which clearly distinguishes it from sibling data-access tools like memory_get or memory_search.

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 second sentence explicitly tells an agent when to use it: checking configuration, model readiness, storage location, and default identity resolution. It does not explicitly name excluded alternatives or when-not-to-use conditions, so it stops short of full routing 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?

With no annotations provided, the description carries the behavioral burden. It discloses that the tool edits an existing fact and that omitted fields retain their values, which defines the update semantics clearly. It does not mention failure behavior or permissions, but the core side-effect contract is stated.

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 two short paragraphs with no filler. The core behavior is front-loaded in the first sentence, and the usage guidance follows immediately, making it easy to scan and apply.

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 six-parameter CRUD update with no annotations, the description covers the operation, partial-update semantics, usage context, and prerequisite lookup. It doesn't detail error cases or return values, but the presence of an output schema reduces the need to explain response structure.

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 adds cross-parameter meaning with 'omitted fields keep their value,' which explains how the optional nullable fields behave. It also tells the agent where to obtain fact_id, reinforcing the key parameter's semantics 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?

The description uses a specific verb-resource pair ('Edit an existing fact by id') and immediately clarifies the partial-update behavior. The follow-up sentence explicitly contrasts it with saving a new fact, distinguishing it from siblings like memory_remember and memory_remember_conversation.

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 explicitly states when to use this tool ('Use this instead of saving a new fact when something changed') and gives a concrete example. It also names the prerequisite ('Get the fact_id from memory_search first'), leaving no ambiguity about the intended workflow.

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