polypack-mcp

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does add useful semantic facts such as 'RESPONDS_TO graph edges are authoritative' and that diagnostics identifies legacy provenance-only relationships, but it never clarifies that add_edge mutates the graph, whether it requires special permissions, or what happens on unsupported/malformed operations.

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 with the core purpose. Every sentence earns its place: the scope, the sibling alternative, and the important authoritative-vs-legacy distinction. It could be slightly more structured, but it has 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?

This is a multi-purpose tool with five parameters, no output schema, no parameter documentation in the schema, and no annotations. The description tells which operations exist but not which fields are required or used for each operation, nor what the return shape or behavior is per operation. An agent would still need to guess several important details.

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. It helps only for 'operation' by naming valid values at a high level, but the meaning and relationship of id, type, source, and target remain entirely unexplained. This is a substantial 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 says specific verbs and resources ('Inspect graph neighbors/schema' or 'perform an advanced edge operation') and distinguishes itself from memory_link for normal relationships. It lists concrete operations, so an agent knows what this tool covers without opening a sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance on when not to use it: prefer memory_link for normal memory relationships. It also enumerates supported operations, making alternative choices clear. It does not give full conditional guidance for each operation, but the main alternative is clearly identified.

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 alone must disclose behavior. It says the result is a durable higher-level memory, but it does not say whether source memories are kept, deleted, modified, or linked, nor whether the operation has destructive 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?

The description is one efficient sentence with the main action and result front-loaded. It is not bloated, though it sacrifices needed detail for 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?

With five parameters, no output schema, zero parameter coverage, and no annotations, a one-sentence description is severely incomplete. It omits parameter role, behavior on source memories, output/return behavior, and usage boundary with sibling 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 0%, so the description must compensate. The phrase 'source memories' loosely maps to source_ids and 'one durable higher-level memory' maps to content, but context, confidence, and memory_class are completely unaddressed.

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 clear action and resource: consolidate source memories into one durable higher-level memory. It implies a merge/abstraction operation that is conceptually distinct from store, recall, link, or supersede siblings, though it does not explicitly name 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 guidance about when to use this tool versus siblings like memory_store_batch, memory_link, or memory_supersede. The context is only implicit in the word 'consolidate'; the description does not state prerequisites, exclusions, or suitable scenarios.

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 disclose behavioral traits. It does disclose a key constraint: 'Each returned memory fits wholly within the remaining budget; budgets must be greater than zero.' However, it does not state whether the operation is read-only, what happens on insufficient budget, how activation affects results, or any ordering/pagination behavior. The single disclosed constraint is useful but incomplete.

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—two sentences—with the primary purpose front-loaded. Every word adds value, and the token_budget constraint is clearly separated. No filler or 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?

Given 4 parameters, no output schema, and no annotations, the description is incomplete. It omits meanings of limit, context, and strict_context, does not describe the output format or ordering, and gives no indication of safety or side effects. It also does not help the agent distinguish this tool from memory_recall. Significant gaps remain for correct invocation and interpretation.

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. It explains token_budget semantics explicitly, but leaves limit, context, and strict_context unexplained. The mention of 'activation' in the first sentence does not map directly to any parameter, leaving most inputs ambiguous. The partial coverage of one parameter is insufficient for a 4-parameter tool with zero schema based 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?

The description clearly states the verbs and resource: 'Return a working-memory set' selected by activation and token budget. It distinguishes itself from siblings (memory_recall, memory_store) by focusing on a set selected by activation/budget, but does not explicitly contrast with them. The purpose is specific and 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?

No guidance is provided on when to use this tool versus alternatives like memory_recall or memory_store. The description explains what it does but not under what conditions an agent should choose it. There is no mention of exclusions, prerequisites, or typical use cases.

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 safety burden. It discloses that the operation is destructive, permanent, affects graph edges, and needs confirmation. While it doesn't cover every edge case (e.g., revision conflict behavior), it transparently conveys the core side effects and safeguards.

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 carry complete high-level guidance: the action, the destructive nature, the confirmation gate, and the alternative. There is no filler or redundancy, and the most critical information is 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?

For a simple, one-required-param delete tool, the description provides the essential behavioral context: what is deleted, how to confirm, and when to choose an alternative. The only meaningful gap is the role of expected_revision and the lack of any return-value hint, but neither prevents correct invocation in the common case.

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. It explains that confirm must be true, which is important, but it says nothing about expected_revision or its semantics for concurrency control. memory_id is self-evident, but expected_revision remains unclear to an agent without additional inference.

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 ('Permanently delete one memory') and adds scope ('and its graph edges'). It clearly distinguishes this hard-delete operation from siblings like memory_suppress and memory_update, so an agent can identify the intent without reading schemas.

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 the confirmation requirement ('requires confirm=true') and names an alternative with a condition ('Prefer memory_suppress when retaining history is useful'). This gives the agent both a prerequisite and a clear routing rule versus a sibling 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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It states that feedback is recorded and when, but it does not explain whether the feedback modifies future retrievals, whether repeated feedback for the same memory_id overwrites prior feedback, or whether this action is reversible. These are meaningful gaps for a memory-system 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?

The description is exceptionally concise: two short sentences with no filler. It front-loads the core action and then adds the practical timing/condition in the second sentence. Every sentence 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?

While the tool is simple, there is no output schema and no annotations, so the description must fully support invocation and behavior expectations. It omits the meaning of agent_id, whether feedback is appended or overwrites, and what the tool does after being called. Given these gaps, the definition is not complete enough on its own.

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 needs to compensate for the parameter definitions, but it only mentions a 'retrieved memory' and 'useful or misleading'. It does not explain what memory_id refers to, how the 'useful' boolean maps to those outcomes, or what agent_id and its default mean. The agent must largely guess the parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Record' and the resource: whether a retrieved memory helped the task. It further clarifies its purpose by specifying the timing 'after using a recalled memory when it was useful or misleading', which distinguishes it from siblings like memory_store and memory_recall without explicitly naming them. The small deduction is for lacking an explicit sibling contrast, but the overall purpose is unambiguous.

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 condition: 'Call this after using a recalled memory when it was useful or misleading.' This tells the agent when to use the tool but not when not to use it or when to choose an alternative, leaving a minor gap for an otherwise simple operation.

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 read-style operation ('Fetch') and that the result includes 'current state and revision', but it does not mention missing-ID behavior, permissions, or whether revision history is also returned. This is minimally transparent but not misleading.

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. Every phrase earns its place: the action, the key constraint ('exact ID'), and the expected content are all included.

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 single-parameter get-by-ID tool, the description is mostly complete: it states what is fetched and what the response includes ('current state and revision'). There is no output schema, so a bit more detail about not-found behavior would improve it, but the core call path is sufficiently clear.

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 only one parameter (memory_id) and schema description coverage is 0%, so the description must compensate. It adds that the lookup is by 'exact ID', which clarifies that fuzzy matching is not appropriate, but it does not explain ID format, provenance, or error behavior. The added meaning is modest but useful.

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 ('Fetch') with a clear resource ('one memory by exact ID') and explicitly names the returned content ('current state and revision'). This clearly distinguishes it from fuzzy/semantic retrieval tools like memory_recall or batch operations like memory_store_batch.

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 phrase 'by exact ID' implies this tool is for precise lookups when an ID is already known, but it does not explicitly state when to use memory_recall or other memory tools instead. There is no when-not-to-use guidance or mention of alternatives, so usage context is only implied.

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

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

The description states the action ('Connect two memories') and implies a persistent graph update, but it does not disclose side effects, safety, validation, idempotency, or response behavior. With no annotations provided, the description carries the full burden, so this is only minimally adequate.

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 three short, front-loaded sentences with no filler. The core action is stated first, followed by practical guidance on the relationship type and a retrieval entry point.

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 core linking intent and points to how to retrieve linked memories. But it leaves out parameter-to-role mapping, return values, and behaviors around missing/invalid IDs. Given no output schema and no annotations, an agent would still have to infer several operational details.

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%, and the fields have only titles and types. The description explains the semantic of RESPONDS_TO as 'a new handoff, verification, or fix addresses an earlier memory,' which helps, but it does not explicitly map source_memory_id to the new memory and target_memory_id to the earlier memory. The description only partially compensates for the schema 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 opens with 'Connect two memories with an explicit graph relationship,' which names a specific verb, resource, and purpose. It is clear and distinct from sibling tools like memory_store or memory_recall, though it does not explicitly position itself against memory_link_batch.

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 clear guidance on when to use the RESPONDS_TO relationship and explicitly points to memory_recall(include_neighbors=true) for retrieving linked memories. It could be stronger by mentioning memory_link_batch for bulk linking, but the direction is 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?

Since annotations are absent, the description must disclose operational details, but it only says relationships are created. It does not state whether existing links are replaced, failed pairs rollback the whole batch, or what happens if memories are missing. The default 'RESPONDS_TO' is useful but not enough.

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 focused: first sentence states purpose and scope, second sentence explains the required shape of each list item. Every sentence earns its place, and the most important usage details 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?

For a one-parameter batch tool, the description explains how to structure a valid call, but does not cover failure modes, idempotency, or allowed relationship values. Since there is no output schema and no annotations, the definition leaves room for guesswork about return values and partial failures.

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 schema only declares an opaque list with `additionalProperties: true`, so the description is the only source of parameter meaning. It clearly documents `source_memory_id`, `target_memory_id`, the optional `relationship`, and its default value. It lacks valid relationship values and exact ID types, but this is a solid compensatory 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 description uses a specific verb ('Connect'), a resource ('multiple pairs of memories'), and a clear scope ('in a single batch'). It distinguishes from the singular memory_link tool by emphasizing batch processing, though it does not explicitly name the alternative.

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 phrase 'in a single batch' implies that this tool is for linking many memory pairs at once, but it does not explicitly state when to prefer it over memory_link or when not to use it. The usage context is reasonable but left largely to inference.

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 full burden of behavioral disclosure. It makes the read-only enumeration behavior clear by using 'List' and describes the returned information. It does not mention edge cases such as whether empty namespaces are included or whether results are ordered, but for a zero-parameter listing tool these are minor omissions.

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, compact sentence that front-loads the action and the result. Every word contributes meaning, and there is no filler or repetition.

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?

This is a very simple tool with no parameters and no output schema. The description states both what is listed and what metric is returned (memory counts per namespace), which is sufficient for an agent to invoke 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?

The tool accepts zero parameters and the input schema has no properties, so there is nothing for the description to add about parameters. The baseline of 4 for a no-parameter tool 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 uses a specific verb 'List' with a clear resource ('context namespaces') and states the exact output ('the number of memories in each'). It is unambiguous and unlikely to be confused with the sibling tools, though it does not explicitly call out how it differs from any sibling.

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 intended usage is implied: an agent should use this tool when it needs an overview of context namespaces and their memory counts. However, there is no explicit guidance about when not to use it or which alternative sibling tool to choose instead.

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 full burden of disclosing behavior, and it does so extensively. It reveals that context is soft by default, depth is silently clamped to at most 3 hops, metadata reports the actual depth, and metadata also reports when additional neighbors were available. These are genuine behavioral insights beyond what the schema alone could possibly convey.

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: purpose first, then usage guidance, then edge-case behaviors. Every sentence contributes meaningful operational knowledge, and there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity — 9 parameters, no annotations, and no output schema — the description is unusually thorough, covering neighbor hydration, depth limits, metadata reporting, and context semantics. It falls slightly short only by omitting token_budget and by not describing the overall return shape beyond mentioning metadata and result counts.

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 largely does. It explains context/strict_context, include_neighbors, edge_types, neighbor_limit versus limit, and depth clamping. However, token_budget is never mentioned, leaving one of nine parameters completely undocumented in behavior and 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 starts with a specific verb and resource: 'Search memories by text, context, activation, and confidence.' It clearly identifies what the tool does and distinguishes it from memory_context by explicitly naming that sibling as the alternative for assembling working context. The occasional mention of activation and confidence could be slightly ambiguous relative to the schema, but the core purpose is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance: 'Use this for a targeted question' and 'Use memory_context to assemble working context.' It also explains when to change behavior with strict_context=true for isolation and how neighbor inclusion works. This is clear, decision-relevant usage guidance with an explicit alternative.

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 itself carries the burden of disclosing runtime behavior. It adds the useful detail that memory is 'durable,' but it does not say whether the call creates or updates an existing memory, whether it may overwrite previous data, what will be returned or persisted, or any notable side effects. That is a significant transparency 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 brief, front-loaded with the primary purpose, and contains no filler or repetition. Every line contributes either to the core verb/resource definition or to the distinction among memory classes needed for correct invocation.

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 six parameters, no output schema, no annotations, and a large sibling toolset, the description leaves important context unstated. An agent cannot determine what the tool returns, how this differs from batch storage or recall, whether context is mandatory, or how memory behaves when stored again.

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?

This description is the only documentation for parameters since schema description coverage is 0%. It valuably explains the memory_class enum values and advises about the context parameter. Still, metadata, confidence, and provenance receive no meaningful explanation, so it only partially compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Store durable project memory.' This clearly communicates the tool's core function. However, it does not differentiate itself from sibling tools like memory_store_batch or memory_recall, so it falls short of a 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?

The description provides solid guidance for the memory_class parameter, mapping procedural, semantic, episodic, and entity memory types to concrete usage patterns. However, it does not say when to choose this tool over related siblings such as memory_store_batch, memory_recall, or memory_suppress, and it offers no explicit exclusions.

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?

Without annotations, the description carries the full burden of behavioral disclosure, but only says the memories are 'durable' and stored as a batch. It does not mention whether writes overwrite existing memories, what happens on partial failure, whether any permissions are required, or what is returned to the caller.

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, front-loads the purpose, and then gives the necessary item-shape guidance without unnecessary padding. Every sentence 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?

Given the single-parameter schema and no output schema, the description covers the main operational need: what to pass in each memory item. It is not fully complete because the semantics and types of optional fields like memory_class, confidence, provenance, and context are left undefined, but the core invocation detail is covered.

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 schema provides only an array of untyped objects, so the description compensates by specifying that each item must be a dict with 'content' and optional keys like 'confidence' and 'metadata'. This is useful, though it does not explain the meaning or expected type of each optional key.

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 the specific verb 'store' with the resource 'durable project memories' and the qualifier 'in a single batch'. This clearly distinguishes it from sibling memory_store by emphasizing batch operation, making the tool's purpose immediately 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?

The phrase 'multiple ... in a single batch' provides clear context for when this tool should be used, i.e., when storing several memories at once. However, it does not explicitly mention memory_store as the single-item alternative or state when not to use this tool, so it lacks explicit exclusions.

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 burden of disclosing behavior. It clearly indicates that this is a write operation that both creates a memory and creates a link, and it explains the direction semantics including how reverse=true changes the relationship. It does not discuss failure atomicity or side effects on the target, but the main behavioral traits are disclosed.

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 three sentences with no filler. The core purpose is stated first, then the usage context, then the important direction behavior. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter write tool with no annotations and no output schema, the description covers the core behavior and the primary use case well. It is less complete regarding what happens on failure, what the return value is, and when a sibling tool like memory_link or memory_store would be preferable, which leaves some ambiguity for an agent.

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 input schema has 0% description coverage, so the description must compensate. It adds meaning for reverse and target_memory_id by explaining that the new memory is the link source by default and the target is an existing memory. However, it leaves many optional parameters like relationship, memory_class, confidence, provenance, and metadata without semantic explanation beyond their schema names and defaults.

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 clear specific action: store a new memory and link it to an existing memory in one call. It explicitly distinguishes itself from the sibling tools memory_store and memory_link by describing how it combines both operations, so an agent can immediately tell when this tool is relevant.

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 use case: storing a reply, verification, or fix that responds to an earlier memory. It also explains the default link direction and the reverse option. It does not explicitly state when not to use this tool in favor of memory_store or memory_link, but the context is clear enough.

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 burden of explaining behavior. It does reveal an important trait: the old fact is not wiped but retained in history. It does not clarify the resulting status of the old memory, whether the new memory must already exist, or whether the operation is reversible.

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?

One short sentence states both the primary operation and the most valuable behavioral consequence with no filler. Every word is functional.

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 two-parameter memory operation, the description is minimally viable: it communicates the main action and the history-preserving behavior. It stops short of guiding the agent on prerequisites, expected outcomes, or return values, which matters because no output schema or annotations are available.

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%, and the description does not explicitly map the two required IDs to 'new memory' and 'old memory'. The parameter names carry most of the meaning, and the description adds only indirect context by referring to an outdated fact and retaining history.

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 action ('Replace') and a clear object ('an outdated fact'), and the qualifier 'while retaining its history' differentiates this from related memory operations such as memory_suppress or memory_store. The purpose is immediately 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?

The phrase 'outdated fact' implies the appropriate use case: to exchange a stale memory for a current one. However, the description does not give explicit when-not-to-use guidance or name an alternative tool for the comparison, leaving the usage context mostly inferred.

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 usefully states the operation is non-destructive ('without deleting it'), but it does not explain whether the inhibition is reversible, what 'inhibit' actually changes about the memory, or how the 'amount' affects the behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It states the action, target, and a key constraint efficiently.

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 no annotations, no output schema, and a schema with undocumented parameters, this description is too sparse. An agent would know what kind of memory to target but would not understand how the amount parameter behaves, whether suppression is reversible, or what the tool returns after execution.

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%, but the description adds no meaning for either parameter. memory_id is obvious but still undocumented, and amount is not explained at all, leaving its scale, units, and effect entirely unclear.

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 gives a specific verb ('inhibit') and a resource ('a stale or unhelpful memory'), and clarifies that suppression does not delete the memory. It does not, however, distinguish itself from the similarly-named sibling memory_supersede, so it stops short of a 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?

The phrase 'stale or unhelpful memory' implies when the tool should be used, but the description gives no explicit comparison to siblings like memory_supersede or memory_feedback, and does not state when it should not be used.

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 burden of behavioral disclosure. It does reveal useful behavioral traits: traversal happens in both directions along RESPONDS_TO edges and results are sorted chronologically. It does not mention output shape, errors, or edge-case behavior, but the core runtime behavior is transparent.

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, giving the essential operation in the first sentence and then enriching it with directional and ordering details in the second. There is minor redundancy between 'return the thread' and 'returning them sorted chronologically', but the overall structure is efficient and readable.

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 tool has no output schema and no annotations, so the description carries significant responsibility. It conveys the main purpose, starting point, traversal direction, and sort order, but it leaves max_depth semantics and the exact shape of the returned thread unstated, which leaves room for an agent to misread the tool's limits.

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 for both parameters. It clarifies 'start_id' as the starting memory ID, but it never explains 'max_depth', such as whether it limits the number of hops or nodes. Given that one of the two parameters is effectively undocumented, the parameter semantics are incomplete.

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 that the tool walks the RESPONDS_TO chain starting from a memory ID and returns the thread, which is a specific verb and resource. It also adds detail about bidirectional traversal and chronological ordering, but it does not explicitly distinguish itself from siblings like memory_context or graph_query.

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 implies usage when a thread of connected memories is needed, but it provides no explicit when-to-use guidance, exclusions, or references to alternative tools. An agent must infer the appropriate use case solely from the tool name and the word 'thread'.

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 full behavioral disclosure burden. It clearly communicates the mutation (removing edges) and the conditional behavior when relationship is omitted: all directed edges from source to target are removed. This is a meaningful nuance beyond a simple 'unlink'. It does not cover return values or failure modes, but the core behavior is transparent.

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 no wasted words. The primary action is front-loaded, and the conditional behavior follows naturally. Every sentence contributes meaningful 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 the simple nature of the tool (3 parameters, no output schema, no annotations), the description covers the essential operational details: what is removed, the role of relationship, and the directionality of edges. It does not mention error behavior or idempotency, but these are not critical for an agent to correctly invoke the tool in most cases.

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 for parameter semantics. It explicitly explains the optional relationship parameter and its default behavior (all directed edges removed when omitted). Source and target memory IDs are self-explanatory from the parameter names and 'from source to target' phrasing. This is sufficient for an agent to construct valid arguments.

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 specific verb 'Remove' and the resource 'graph edges between two memories', which distinguishes it from sibling tools like memory_link (which likely creates edges) and memory_delete (which likely deletes entire memories). The purpose is unambiguous 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 implies the tool is used when you want to remove edges between two memory nodes, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or contraindications. The guidance is adequate but relies on inference.

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. It discloses that content is preserved, enumerates mutable fields, and explains that expected_revision prevents overwriting a concurrent update. It does not cover return values, error behavior, or permissions, but the core mutation semantics are transparent.

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-loaded with the primary behavior, followed by supported fields, the sibling alternative, and the concurrency note. Every sentence adds value and there is no filler or repetition of schema details.

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 3-parameter update tool with no annotations and no output schema, the description covers purpose, allowed patch fields, the key alternative, and the expected_revision parameter. It omits error handling and return behavior, but an agent has enough context to invoke the tool correctly in typical cases.

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 compensates by naming the supported patch fields and giving expected_revision its concurrency-protection meaning. memory_id is self-explanatory from its name, though patch value types are not specified; overall the essential parameter semantics are provided beyond the bare 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: 'Update mutable memory fields without changing its content.' The explicit boundary between updating fields and content, plus the list of supported fields, makes the purpose clear and distinguishes it from memory_supersede and other siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly directs the agent to 'Use memory_supersede when the memory content itself needs to change,' providing a clear when-not-to-use condition. The description also implies when memory_update is appropriate: when only context, confidence, provenance, or metadata need updating.

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