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

With no annotations, the description carries the full burden, and it does disclose the most important runtime trait: Hindsight ingest is async by default so the call returns before LLM extraction completes, avoiding client timeouts. It does not cover failure modes, deduplication/overwrite behavior on existing content, or how the 'active' provider is resolved.

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, front-loaded with the action and scope, then the one non-obvious operational caveat. Every clause earns its place and nothing is repeated verbatim from the schema.

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 mutation tool with no annotations and no output schema, the description should say what is returned (an id? a confirmation?), whether repeated content dedupes, and how the active provider is chosen. The async caveat is well covered, but those gaps leave an agent guessing about return handling.

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 all four parameters (including the bank scoping dual-purpose and async flag) are already documented in the schema; the description's provider list merely echoes that. The vague `metadata` field ("provider-specific") gets no clarification beyond the schema in either place.

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 text") and resource ("active memory provider"), and enumerates the concrete backends (Hindsight bank, mem0 user scope, Cognee dataset). It is clearly the write counterpart to siblings like memory_recall and memory_search, but it never names those siblings to draw the contrast explicitly.

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 purpose implies when to call it (persisting text), and the async note gives runtime guidance, but there is no explicit when-to-use guidance versus memory_import, memory_consolidate, or memory_reflect, nor any statement of prerequisites or what should not be added.

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, and it discloses almost nothing: no statement of whether consolidation mutates or deletes stored memories, whether it is reversible, how long it runs, or what it costs. The one genuine behavioral signal is that mem0 is skipped, which is useful but far short of adequate for a maintenance operation on a memory store.

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?

It is a single compact sentence with no padding, and the 'Provider maintenance:' prefix is correctly front-loaded. However, the compression is achieved by dropping connectives and articles, producing telegraphic fragments whose ambiguity is not offset by brevity.

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 zero annotations, an undocumented sole parameter, and no output schema, the description should explain effects and return behavior. Instead it offers three provider-specific fragments, leaving an agent unable to predict what happens after the call.

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% for the single 'bank' parameter, and the description only obliquely alludes to it via 'for a bank/dataset'. It never says whether bank is required, what an omitted bank means (all banks?), or what a valid identifier looks like, so it fails to compensate for the coverage gap.

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 leading phrase 'Provider maintenance' gestures at an administrative operation, but the rest is provider-specific jargon ('Cognee cognify', 'Hindsight notes LiteLLM route') that never states in plain terms what the tool actually does. 'Consolidate' plus the fragmented provider clauses does not let an agent distinguish this from memory_reflect or memory_provider_status with confidence.

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?

There is no guidance on when to invoke this versus any of the nine siblings, no preconditions, and no exclusions. The 'mem0 skips' fragment implies a provider-specific no-op but never frames it as an invocation rule, so an agent has no basis for routing 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?

No annotations exist, so the description must carry the full burden: it discloses the supported formats and which provider endpoints back each bank type, and notes the all-banks option. It never states that this is a read-only operation, whether exports are paginated/streamed, or any size/time limits, so a mutation-free export is left to inference.

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 with the core action and formats front-loaded, zero repetition of the name. The provider-endpoint shorthand is dense but earns its place as implementation context.

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 two-parameter, zero-required export with full schema coverage and no output schema, the description covers action, target format and per-provider source behavior. Missing read-only/pagination notes are minor rather than blocking for a correct call.

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 both parameters are already documented; the description only echoes the format enum and the bank's role for Hindsight listings without adding syntax, defaults beyond the schema, or examples. Baseline 3 is correct when the schema does the heavy lifting.

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 ('Export memories') plus the target serialization ('PMM v1 (json/jsonl)'), which cleanly separates it from memory_import, memory_recall and memory_search. It does not name a sibling explicitly, so it falls short of 5.

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?

Usage is only implied by the verb 'export' – the agent can infer backup/migration rather than live retrieval, but there is no explicit 'use this when' or exclusion against memory_recall/memory_search. The second sentence routes per-provider behavior but says nothing about when to choose this 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?

No annotations are provided, so the description carries the full burden. It does disclose the destructive scope (single memory vs. entire bank), but omits irreversibility, confirmation requirements, and what happens if both parameters are supplied — significant gaps for a delete 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?

A single sentence that front-loads the primary action and then the conditional second mode. No filler, nothing redundant with the schema.

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 annotations and no output schema, the description covers the two modes but leaves out preconditions, irreversibility, and result behavior. Adequate to call correctly, but not fully complete.

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; however the description adds meaning beyond the schema by explaining the interaction between the two parameters — that bank without memory_id triggers a whole-bank drop. That conditional semantics is not inferable from the schema alone.

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 (delete/drop) with two clearly delineated resource modes: a single memory by id via mem0, or an entire Hindsight bank. This is readily distinguishable from siblings like memory_recall, memory_search, and memory_add.

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 a concrete routing rule: pass bank alone to drop a bank, pass memory_id to delete a single memory. It does not explicitly name alternatives or state exclusions (e.g., when to prefer memory_consolidate), so it stops 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?

No annotations are provided, so the description carries the full burden. 'Best-effort cross-provider' usefully discloses that partial or lossy imports are possible, but nothing is said about write/permission requirements, reversibility, idempotency, or how merge_strategy affects existing data — large gaps for a mutation 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?

A single front-loaded sentence with no filler. It is arguably too terse given the tool's complexity, but nothing is wasted.

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 no annotations, no output schema, and one of two parameters undocumented, the description should explain the merge semantics and what the agent gets back or what can be lost. As written, an agent cannot call this safely with confidence.

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 only 50%: 'data' is documented as a serialized payload and the description adds that it is a PMM v1 format, but merge_strategy has no schema description and the description never explains skip_duplicates vs overwrite. The description therefore fails to compensate for the undocumented parameter.

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 ('Import') and resource ('PMM v1 payload') with a target ('the active provider'), which distinguishes it from siblings like memory_export and memory_add. 'PMM v1' and 'active provider' are unexplained jargon, but the import operation itself is identifiable.

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?

No guidance on when to use this versus memory_add or memory_consolidate, nor any prerequisites about provider state. The only contextual hint is 'best-effort cross-provider,' which implies behavior but does not route the agent among 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?

With no annotations, the description carries the full disclosure burden. It usefully clarifies that the tool reads local state and makes no memory-provider calls, but it does not describe permissions, failure behavior, or what the returned mapping/policy looks like.

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 definition is two front-loaded sentences with no filler. The purpose is stated first, followed by the key non-provider behavioral constraint.

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 local read with one optional, fully documented parameter, the description gives enough context to call the tool correctly. The main omission is that, with no output schema, it does not describe the return shape beyond naming the data categories.

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?

The single optional parameter is fully described in the schema, so the baseline is 3. The description adds no parameter-level meaning beyond what the schema already provides for 'cwd'.

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 ('Read') and precise resource ('local project bank mapping and session access policy for a workspace'). It also differentiates itself from provider-backed siblings by noting 'Makes no memory-provider calls', though it does not name specific alternatives.

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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternatives. The negative behavioral note ('no memory-provider calls') hints at a local-only scope but does not tell an agent when to choose this tool over memory_recall or memory_provider_status.

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 disclosure burden. It does add real value by implying a read-only operation and explicitly promising "no secrets" are returned (redaction behavior). However it does not say what happens when MEMORY_PROVIDER is unset or how the URL is resolved (env vs. config vs. default), which are the questions this tool exists to answer.

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?

A single front-loaded sentence with the parenthetical caveat placed where it matters. Nothing is wasted and nothing needs to be trimmed.

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 zero-parameter tool with no output schema, the description effectively doubles as the return-value contract (provider name, resolved URL, secrets excluded). The only missing piece is the unset/unresolved case, which is minor.

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?

Zero parameters, so the baseline is 4. The description also adds light semantics about the return surface by distinguishing the raw MEMORY_PROVIDER from the "resolved" backend URL, but there are no parameters to explain.

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 ("Report") and a specific resource (active MEMORY_PROVIDER plus resolved backend URL). It is unambiguously distinct from every sibling, which all perform recall/add/search/export operations rather than diagnostic status reporting, though it never names a sibling to contrast with.

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?

Usage is only implied: an agent can infer you call this to discover which memory backend is in effect, but there is no explicit when-to-use statement, no preconditions, and no alternatives named. For a simple diagnostics tool this is minimally adequate.

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 must carry the behavioral burden. It mentions the backend APIs but does not describe whether the operation is read-only, what it returns, whether it mutates state, or any permission/rate-limit considerations.

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 a single, front-loaded sentence with no padding. The parenthetical about Hindsight/mem0/Cognee is somewhat tangential but still compact.

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 no annotations, no output schema, and three undocumented parameters, the description leaves significant gaps. It does not tell an agent enough about behavior, return values, or parameter usage to call the tool confidently.

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 should compensate for all three parameters. It only indirectly maps 'query' to 'a question'; the 'bank' and 'limit' parameters are not explained at all.

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 and resource: 'Retrieve context for a question.' It is clear what the tool does in general, but it does not distinguish this from the sibling memory_search beyond a vague parenthetical about underlying implementations.

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 implies the tool is for question-answering context retrieval, but gives no explicit guidance on when to choose memory_recall over memory_search or memory_reflect. There are no exclusions or prerequisite conditions.

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 does add useful behavioral context: behavior varies by provider, and mem0/Cognee may perform search plus optional LiteLLM synthesis using PM_LLM_URL. However, it does not state whether the call is read-only, whether it persists anything, expected cost/latency, or auth requirements beyond a config variable name.

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?

It is compact and front-loads the purpose in the first sentence. The second sentence is dense with unexplained names and acronyms (Hindsight, mem0/Cognee, PM_LLM_URL, stack LiteLLM), reducing its practical clarity.

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 three undocumented parameters, no annotations, and no output schema, the description leaves significant gaps: parameter meanings, return shape, side effects, and selection guidance versus siblings are missing. The provider routing note helps, but not enough to make the definition complete.

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%. The description only implies that 'query' is the question being synthesized, while 'bank' and 'limit' are left entirely 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?

The first sentence states a specific verb and resource: 'Synthesize session context for a question.' The second sentence distinguishes this from lower-level siblings by naming recall/search as internal steps, though the provider jargon makes the boundary less crisp than it could be.

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?

Usage is only implied: synthesize context for a question, with recall/search mentioned as internal mechanisms. There is no explicit rule for when to choose this over memory_recall or memory_search, nor 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?

With no annotations, the description carries full burden, and it discloses almost nothing behavioral: not whether the call is read-only (implied only by the verb 'search'), not whether 'active provider' must be configured first, not what happens when the provider doesn't support limits, and not what result shape to expect. One clause about the two search modes is the only added context.

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?

A single front-loaded sentence with no filler or redundancy. It is tight, though the brevity edges into under-specification rather than optimal density.

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?

No output schema and no annotations, so the description must cover more: it should say what a result contains, whether ordering/relevance scores are returned, and how provider selection and limits interact. For a search tool in a nine-sibling memory family, this leaves the agent guessing on core call semantics.

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 only 67%, and the undocumented parameter is the required one: 'query'. The description says search may be 'semantic or graph' but never explains how the query string is interpreted differently in each mode, nor what 'active provider' means for scoping alongside the 'bank' parameter.

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 names a specific verb (search) and a specific resource (memories), and adds the useful qualifier that it can be semantic or graph-based and operates against the active provider. That distinguishes it from mutating siblings like memory_add or memory_forget, though it doesn't explicitly contrast with the closest alternative, memory_recall.

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?

There is no guidance on when to choose this over memory_recall, or over memory_reflect/memory_project_scope. The only usage signal is implicit — that it's a query tool — and nothing says when-not to use it or what prerequisites (an active provider, a populated bank) are required.

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