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

No annotations are provided, so the description carries the full behavioral burden. It does disclose a meaningful trait beyond the schema: that sector defaults to an automatic classification the caller can override, and that metadata 'type' improves later filtering. However, it says nothing about deduplication/uniqueness, permissions, or side effects, which matter for a write tool with no annotation coverage.

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 core action, then a compact run-through of each parameter. No filler sentences, and the per-parameter notes are dense with useful guidance rather than padding.

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 exists, so return values need not be described. With 0% schema description coverage across four params, the description compensates for all of them meaningfully. The main remaining gap is the absence of any durability/duplication or permission behavior for a write operation lacking annotations.

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 must carry parameter meaning, and it does: content is scoped to "one self-contained fact, with absolute dates," sector enumerates the five classification values as an override, and metadata 'type' is given concrete examples (system_info, preference, decision, troubleshooting). Only 'tags' is left with bare "optional" and no semantic guidance.

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?

Clear specific verb+resource: "Store a new memory." The action is unambiguous and easily distinguished from siblings like get_memory, delete_memory, search_memories, and reinforce_memory. It does not explicitly name or contrast with any sibling, so it stops short of the top band.

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 implied by the purpose (use this to persist a new fact), but there is no explicit when-to-use/when-not guidance and no routing to alternatives. Notably it does not address when to add a fresh memory versus reinforcing an existing one (reinforce_memory), leaving a real ambiguity for the agent.

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 behavioral burden. It usefully discloses that deletion is permanent and cascades to vectors and links, which is real value beyond the name. However, it omits permission requirements, behavior when the memory_id does not exist, and idempotency, which matter for an irreversible mutation.

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 short sentences, front-loaded with the destructive action and followed immediately by the safer alternative. Every clause earns its place with no padding.

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 exists, so return values need no explanation, and a single-parameter delete is well served by the stated permanence and cascade behavior plus the alternative-route guidance. Only edge-case behavior (missing id, permissions) is left uncovered.

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?

There is one required parameter whose schema description coverage is 0%, so the description should compensate but does not explain what memory_id accepts or how to obtain it. The meaning is largely inferable from the tool name, so this is adequate rather than deficient.

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 adds the destructive scope ('its vectors/links'), which tells the agent this is a cascading hard delete rather than a soft flag. It also implicitly contrasts with add_memory by recommending correction over deletion. It does not name siblings by name, so it stops short of full differentiation.

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 'Prefer adding a corrected memory over deleting,' which routes the agent to the add_memory alternative and gives a when-not-to-use condition. There is no guidance on confirmation, prerequisites, or when deletion is genuinely the right call, so it is clear but not complete.

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 retrieval returns 'full metadata', which is useful behavioral context, but says nothing about error behavior, whether missing ids raise or return empty, permissions, or rate limits. For a read tool this is partially adequate but thin.

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 tight sentence with no waste, and the identifying action and scope are front-loaded.

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 exists, so return-value explanation is not required. However, with no annotations and an undocumented parameter, the definition leaves the agent without when-to-use routing or id-format guidance; it is minimal but not incorrect.

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 single parameter 'memory_id' is undocumented in the schema. The description names the lookup key ('by id') implying it must be an exact/memory id, but adds no format or source detail, so it only minimally compensates for the coverage gap. With 1 parameter the baseline is a 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?

States a specific verb (Fetch) and resource (memory) with scope qualifier 'by id' and 'full metadata'. This distinguishes it from search_memories and semantic_search, which retrieve memories by query rather than by exact id, though it doesn't name those siblings 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?

No guidance on when to use this vs the sibling retrieval tools. An agent cannot tell from the description whether this is the right choice when it has an id versus needing to search; nothing addresses prerequisites or 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?

No annotations are provided, so the description carries the full burden. It usefully discloses what the report surfaces (backend status, embedding provider, sector counts/salience), but never states that it is a side-effect-free read, whether it requires auth, or whether it is expensive/rate-limited. A health check is conventionally safe to call, so this is a moderate rather than severe 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?

A single front-loaded sentence that enumerates exactly the three things returned, with no filler or redundancy. Every clause 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?

With no parameters and an output schema present, the description need not explain return values, and it correctly orients the agent to a read-only diagnostic. The only shortfall is the absence of any usage context, which is minor for a zero-argument health probe.

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 tool takes zero parameters, which is the baseline-4 case. Nothing about arguments needs explaining, and 100% schema coverage leaves no ambiguity.

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 resource (backend health) and enumerates the report's contents: embedding provider and per-sector counts/average salience. That clearly separates it from the CRUD/search siblings, though it reads as a noun-phrase output list rather than an explicit verb+resource statement.

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 when-to-use guidance, no mention of when a diagnostic check is appropriate (e.g. troubleshooting, startup validation), and no reference to alternatives. Usage is only implied by the tool name.

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. It does disclose useful behavior: results are ordered newest-first and pagination is supported. It omits auth/permission requirements, default page size behavior beyond the schema default, and what happens at the end of the result set.

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 short sentences, front-loading the ordering behavior an agent needs most. Nothing is wasted, though 'with pagination' is slightly redundant given the limit/offset parameters.

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 exists, so return values need not be explained. Still, for a three-parameter tool at 0% schema coverage with several similar retrieval siblings, the description leaves limit/offset semantics and sibling routing unaddressed.

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%, leaving limit, offset, and sector undocumented in the schema. The description compensates partially by explaining that sector filters on the primary sector and that limit/offset drive pagination, but gives no defaults, ranges, or format guidance.

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 ('List memories') plus ordering ('newest first') and pagination support. It does not explicitly contrast itself with the sibling search_memories or semantic_search, so the distinction must be inferred from the verb.

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 implied: this is the unfiltered enumeration path versus the sibling search tools, and 'sector optionally filters' hints at narrowing. However nothing states when to choose this over search_memories or semantic_search, and no exclusions are given.

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. It discloses two behaviors: raising salience by a boost amount and marking as seen now. However, it doesn't clarify the scale of salience (is it 0-1? unbounded?), whether operations are idempotent, what happens if memory doesn't exist, or permission requirements. There's an output schema, so return values are covered elsewhere, but mutation semantics remain thin.

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?

Single, dense sentence that front-loads the action and includes the key parameter constraint inline. No wasted words; every part carries meaning.

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 simplicity (2 params, output schema exists), the description covers the core operation and the non-obvious boost constraint. It lacks usage context and the memory_id meaning, but for a simple reinforcement tool, it's largely complete. The main gap is not addressing what happens if the memory doesn't exist.

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%, so the description must compensate. It defines 'boost' as (0..1, default 0.1), which adds crucial constraint information not in the schema (schema just says number). However, 'memory_id' is completely undocumented in both places. Partial compensation for the coverage gap, but the required parameter is left unexplained.

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 (raise) and resource (memory's salience/importance), with detail on the effect and timestamp marking. Clearly distinguishable from siblings like add_memory or searched_memories by its reinforcement semantics, though it doesn't name any alternatives 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?

No indication of when to use this versus alternatives. An agent must infer that this is for reinforcing existing memories, but there's no guidance on context, prerequisites (e.g., memory must exist), or when not to use it. No alternative tools mentioned.

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 behavioral burden and does address the key trait by declaring 'no side effects' (a read-only guarantee) plus provider independence. It omits any note on result ordering, scoring, or how k interacts with the result set, which keeps it short of a 5.

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?

Purpose and the key differentiator are front-loaded in the first sentence, followed by a tight per-parameter walkthrough. No filler sentences; every line adds information the agent needs.

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?

Return shape is covered by the existing output schema, so the description only needs selection and invocation guidance, which it largely provides. The only gap is the meaning of k and whether results are ranked or truncated.

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 must compensate, and it documents three of four parameters — query, sector (including the valid enum values not present in the schema), and require_all. Only k is left undocumented, a minor gap for an obvious result-count 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+resource ('Keyword (BM25) search over all memories') and immediately scopes it against the embedding-based sibling by noting it works regardless of embedding provider. An agent can distinguish it from semantic_search 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?

Gives clear when-to-use guidance ('best for exact terms such as hostnames, ports, file paths, names'), which is a precise trigger condition. It does not explicitly name semantic_search as the contrasting alternative, but the BM25 framing makes the routing obvious.

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 delivers two non-obvious behavioral facts: the tool mutates state ('marks every returned memory as seen and raises its salience slightly, so it also acts as reinforcement') and degrades to random results without a real embedding provider. Auth needs, rate limits, and result ordering are still unstated.

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 dense sentences, with the purpose and the provider caveat front-loaded; every sentence adds information. The parenthetical mechanism list is slightly cluttered but not wasteful.

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 exists, so return values need no explanation, and the description covers purpose, suitability, a prerequisite, and side effects. The remaining gap is the un-explained k and sector parameters, which leaves an agent guessing at result count and scoping.

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% for three parameters (query, k, sector), yet the description explains none of them — k's default count and sector's filtering role are entirely undocumented. 'Questions phrased in your own words' loosely gestures at query, but the description 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 description states a specific verb+resource ('Meaning-based search') plus the mechanism (embeddings + salience + recency + links) and the query style it suits ('questions phrased in your own words'). This implicitly contrasts with the lexical sibling search_memories, but it never names the sibling, so an agent must still infer the routing.

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 a clear condition for use ('Good for questions phrased in your own words') and a strong prerequisite gate via health_check ('Only meaningful when health_check shows a real embedding provider ... with synthetic results are random'). It does not, however, explicitly say to use search_memories instead for keyword/exact queries.

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