Nexus Memory

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

With no annotations, the description carries the full burden. It discloses the side effect (creates a file), the destination path, the content scope (payloads + vectors), and the automated schedule. It stops short of describing overwrite/collision behavior or return value, which would make it fully 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 each carry distinct value: what is created, where it is saved, and when to use it manually. There is 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?

For a zero-parameter tool with no output schema, the description covers the core invocation details: action, scope, destination, schedule, and on-demand intent. It could mention the success/return value and existing-backup behavior, but these are minor gaps for a simple backup operation.

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 has zero parameters, so the schema is complete by default and no parameter documentation is needed. The description's mention of 'full backup' and 'payloads + vectors' adds context that an agent does not need parameters to act on.

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 ('Create'), a clear resource ('all memories'), and a concrete artifact ('JSON file'), while specifying it includes payloads and vectors. This is unambiguous and distinct from sibling operations like restore, remember, or 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?

Explicitly frames the tool as manual on-demand backup ('use this for manual backup on demand') and notes that the same operation runs automatically every 24h. It does not name alternative tools or exclusions, but it gives enough context to select it over unrelated siblings.

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 full burden of behavioral disclosure. It conveys that this is a check rather than a mutation, but it does not disclose whether it makes a network call, what it returns, how 'newer' is determined, or any auth/rate-limit implications.

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 is front-loaded with the action and target. There is no wasted wording or redundant restatement of the tool name.

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 zero-parameter check, this minimal description is mostly sufficient for invocation. However, with no output schema, the description leaves the return value and success/failure semantics to inference, which is a notable gap.

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 has zero parameters and the schema coverage is effectively 100%, so the baseline of 4 applies. No parameter documentation is needed because there is nothing to configure.

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 ('check') and resource ('if a newer version is available on GitHub'), making the tool's purpose immediately clear. It semantically differs from mutation siblings like update and do_update, but it does not explicitly call out that distinction.

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 no guidance on when to use this tool versus update/do_update, nor does it state prerequisites or exclusions. The intended context is loosely implied, but no explicit routing is provided.

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 clearly discloses the return type (human-readable explanation) and its content (provider and rationale), and the verb 'explain' implies no state mutation. It does not mention rate limits or cost effects, but those are less critical for an explain-style 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 compact, front-loads the tool's purpose, and avoids unnecessary detail. 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?

For a single-parameter explain tool, the description sufficiently covers the input and the return value, with no output schema to duplicate. The only notable omission is guidance relative to cost_routing_stats, which is already accounted for under usage_guidelines.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the category parameter and its allowed values. The description adds no additional parameter-level meaning beyond framing it as a memory category, so the baseline score of 3 is appropriate.

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

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

The description uses a specific action ('explain') and resource ('routing decision for a memory category') and states the output: which provider will be used and why. It is clear, though it does not explicitly differentiate itself from the sibling cost_routing_stats.

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: use when a human-readable explanation of a routing decision is needed. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives such as cost_routing_stats.

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 transparency burden. It does convey that the tool is read-oriented (get/shows) and lists what information it returns, but it doesn't explicitly state lack of side effects, freshness, auth requirements, or any caveats about the stats. This is acceptable for a no-parameeter stats tool but not rich.

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 short, front-loaded, and every sentence adds detail about what the tool exposes. The 'Cost-Aware Routing' prefix gives context and the following sentences name the specific outputs without fluff.

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 low-complexity, no-arameter tool, and the description names three concrete output categories: available providers, routing decisions, and tier configuration. Since there is no output schema, the description supplies the essential return-oriented information; a little more detail about time ranges, aggregation, or output format would make it 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?

The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. Per the rubric, 0 params earns a baseline 4; the description adds no unneeded parameter noise.

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, 'Get statistics', and a specific resource, 'embedding provider routing', and lists the content involved (providers, routing decisions, tier configuration). It is clearly about a stats/overview tool, not a modifier or memory tool. It doesn't explicitly contrast with the sibling cost_routing_explain, so it doesn't fully distinguish itself from that likely related tool.

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

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

There is no explicit guidance about when to call this tool rather than a sibling such as cost_routing_explain or the other memory/health tools. The phrasing 'Get statistics' gives a weak implicit use case, but no context, prerequisites, exclusions, or alternative routing guidance is provided.

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 does mention pulling from GitHub and reinstalling, which implies network use and installation changes, but it omits side effects like service interruption, data persistence, rollback options, or the confirmation requirement. This is a meaningful gap for a tool that modifies an installation.

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

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

The description is two short sentences with no filler. The core action is front-loaded, and the mechanism follows immediately. Every word earns its place.

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

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

Given the existence of a similarly named sibling 'update' and the potentially disruptive nature of reinstalling software, the description lacks critical context about when to use this tool and what side effects to expect. The schema covers the confirmation flag, but not usage boundaries or behavioral caveats, leaving an agent under-informed.

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 description for the 'confirm' parameter is complete, covering its role as a safety guard, and schema coverage is 100%. The tool description itself adds no parameter information, but per the baseline for high schema coverage, a 3 is appropriate.

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

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

The description clearly states the action ('Update'), the resource ('Nexus Memory'), and the method ('pulls from GitHub and reinstalls'), making the tool's function specific. However, it does not differentiate itself from the sibling tool 'update', which could easily be confused with this one.

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 offers no guidance on when to use this tool versus alternatives like 'update' or 'check_update'. The only implicit signal is 'to the latest version', but there are no explicit conditions, exclusions, or decision criteria for an agent to route correctly.

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 and does disclose non-obvious behavior: it follows a chain, includes both successors and predecessors, and orders results by valid_from. It does not mention output format or error cases, but the read-only nature is strongly implied by 'Trace' and 'Shows'.

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, front-loaded sentences: the first states the operation, scope, and ordering; the second gives the user-facing purpose. Every word earns its place, with 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?

For a single-parameter read tool, the description explains what is returned and how it is ordered, which is the core of correct invocation. It omits edge-case behavior such as unknown or invalid memory_id and does not describe the exact response shape, but the operation is simple and no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline applies; memory_id is already described as 'ID of the memory whose history to trace.' The description adds context about what the history includes, but does not add syntax or format details for the parameter itself.

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 ('Trace') and a specific resource ('supersession chain of a memory'), and clarifies the exact contents: the point itself, successors, predecessors via superseded_by, and ordering by valid_from. This clearly distinguishes it from generic graph/query siblings like graph_traverse or get_related.

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

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

It clearly signals the context for use: when you need to see how a memory/fact evolved through supersession over time. It does not explicitly name alternatives or exclusion conditions, but the scope language makes the appropriate use case evident.

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 carries the behavioral disclosure burden. It establishes a read-only operation via 'Find' and documents the return dict fields, which is useful. However, it does not disclose how the limit interacts with 'all', what a blank entity_type returns, or any ordering/pagination behavior, leaving those to schema defaults.

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 concise sentence: scope prefix, action, resource, and return format. It is front-loaded, contains no filler, and does not redundantly repeat parameter details already present in the schema. Every part earns its place.

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

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

For a simple tool with two optional parameters and no output schema, the description covers the main call contract and the return keys. It does not specify the behavior when entity_type is omitted or how the limit affects the 'all' claim, but the input schema covers defaults and allowed values. These are minor gaps for a tool of this complexity.

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% with both parameters documented, so the baseline is 3. The description's mention of entity_type in the return dict slightly reinforces the filter parameter but adds no new semantic detail about parameter usage. No compensation is needed beyond the baseline.

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 'Find' with the resource 'entity-typed memories in Qdrant' and states the exact return shape. The 'Knowledge Graph' prefix and focus on entity types distinguish it from generic memory siblings like recall and get_related. This is a clear, unambiguous purpose 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?

The description implies that this tool is for retrieving entity-typed memories but gives no explicit when-to-use guidance or alternatives. It does not name siblings such as recall or graph_traverse, so an agent must infer the right routing from the 'entity-typed' qualifier. This meets the implied-usage bar but leaves selection to judgment.

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 states that the tool deletes a memory, which signals a destructive operation, but it does not disclose whether deletion is permanent, what happens if the ID does not exist, or whether related data is affected.

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 wasted words. It immediately communicates the operation, resource, and required input.

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 is simple, with one required parameter and no output schema, so the description covers the basic call correctly. However, it omits behavioral context like irreversibility and failure semantics, which would be particularly valuable for a destructive operation with no 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 coverage is 100% and the schema already clearly documents memory_id as 'ID of the memory to delete'. The description adds no meaningful parameter detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific action verb ('Delete') and names the exact resource ('a specific memory') along with the identification mechanism ('by ID'). This clearly distinguishes it from sibling tools like remember, recall, update, and restore.

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 when to use the tool: when a specific memory must be deleted by its ID. However, it gives no explicit guidance about alternatives, such as restore for recovering deleted memories, or when forgetting should be avoided.

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 disclosure burden. It does meaningful work by disclosing bidirectionality and the exact return schema ({fact_id, relation, edge_id, direction}), and 'Get' implies a read with no side effects. It lacks explicit read-only/safety language, pagination, or missing-fact behavior, but for a simple query tool the disclosed traits are substantive.

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 terse sentences with zero waste: the purpose and scope qualifiers are front-loaded, followed by the return shape. The 'Knowledge Graph:' prefix orients the agent instantly, and 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?

The return-shape disclosure compensates well for the missing output schema, and params are fully covered by the schema. However, with no annotations, the description omits a safe-to-call statement and any pagination/limit or not-found behavior for a potentially large 1-hop result set. It also doesn't route the agent toward graph_traverse or get_subgraph, which is notable given the sibling set.

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 schema already documents fact_id as 'The Qdrant point ID to find neighbors for' and relation with an example. The description doesn't add parameter-specific meaning beyond the schema; '1-hop, bidirectional' enriches tool behavior rather than param semantics. Baseline 3 is appropriate.

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

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

The description identifies a specific verb ('Get'), a concrete resource ('directly related facts'), and precise scope qualifiers ('1-hop, bidirectional'). This clearly distinguishes it from sibling tools like graph_traverse (multi-hop) and get_subgraph (broader structure), and it even specifies the return item shape.

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 '1-hop' qualifier implies this tool is for direct neighbors only, which implicitly signals that deeper traversals belong to another tool, but no alternative is named and no explicit when-to-use/when-not-to-use guidance is given. Given the presence of graph_traverse, get_subgraph, and find_entities as siblings, explicit routing would meaningfully improve agent selection.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly describes the return shape ({nodes, edges}) and field semantics (id, depth, source, target, relation), giving the agent a concrete behavioral contract. It does not explicitly state read-only/no side effects, but 'Get' and 'visualization' strongly imply a query operation.

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, front-loaded sentences deliver the purpose first and then the return contract. There is no filler, repetition, or unnecessary detail.

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 visualization-focused subgraph query, the description supplies the essential return contract and center concept, while the schema covers parameters and constraints. It omits traversal-direction or cycle-handling details, but these are not critical for basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents both parameters (fact_id, max_depth) with 100% coverage, so the baseline is 3. The description's 'centered on a fact' and node 'depth' echo the parameters but add no new syntax or format details beyond what the schema provides.

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

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

The description names a specific resource ('subgraph centered on a fact'), a clear verb ('Get'), and a purpose ('for visualization'). It distinguishes itself from generic graph tools like graph_traverse by emphasizing the fact-centered focus, though it does not explicitly name sibling 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?

'For visualization' provides some context for when to use this tool, but the description does not mention alternative tools like graph_traverse or get_related, nor does it state conditions that should route the agent elsewhere. The usage guidance is implied rather than explicit.

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 burden. It discloses the return format as a list of {fact_id, depth, relation, path} dicts and the traversal nature, but it does not explicitly state that the operation is read-only, nor does it mention behavior on missing starting facts, cycles, or depth limit handling.

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: the first establishes purpose and scope, the second gives the output contract. There is no filler, and the key behavioral 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?

The schema fully documents the parameters, and the description provides the purpose and return structure, which is enough for a first correct call. However, there is no output schema and the description does not cover edge cases such as empty results or how optional filters interact with traversal, leaving some context on the table.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already documents, but it does not need to because each parameter has a clear 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 states a specific verb and resource: "Multi-hop traversal from a starting fact." It also frames the exact question it answers, "what is connected to X?", which clearly distinguishes it from sibling tools like get_related or get_subgraph by emphasizing multi-hop traversal and the starting-fact requirement.

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 "Answers 'what is connected to X?'" provides a clear, concrete context for when to use the tool. It does not explicitly name alternatives or exclusion conditions, so it does not reach the 5-level of explicit when/when-not guidance.

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

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

Wih no annotations, the description carries the full burden and does a good job: it discloses that the tool queries Nexus Memory for protection rules, the category and keyword criteria used, and the form of the result. It clearly frames the tool as a check, implying no mutation, though it does not explicitly state side-effect-freeness.

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 descripion is compact and well-structured: purpose first, mechanism second, usage third. Every sentence contributes meaningful information, and the examples are concrete without being verbose.

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 output schema, the descripion gives a sufficient summary of the return verdict (allow/block/override) and the circumstances for invocation. It could be slightly more complete about how 'override' is interpreted and exactly how tool_input is used in path-based checks, but overall it is adequate for an agent to select and call the tool 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 input schema already documents all three parameters with 100% coverage, so the descripion does not need to add parameter-level detail. The description provides useful context about why command/tool_input matter (safety checks on destructive ops) but does not add semantics beyond the schema.

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

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

The descripion states a specific verb and resource: check if an action is safe by querying Nexus Memory, and identifies the return verdict (allow/block/override). This is clear and useful, though it does not explicitly distinguish itself from the sibling guardrail_override beyond implying this tool is a pre-execution check.

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

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

It explicitly directs usage before destructive operations with concrete examples (rm, drop, kill, overwrite, recreate). This provides clear context for when to call it, but it does not discus when not to use it or name alternatives like guardrail_override.

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 transparency burden. It discloses the key side effect: the override 'is stored as a private session memory entry for audit' and that a full audit trail is maintained. It fall short only in not addressing permissions, reversibility, or return behavior, but the storage and privacy disclosure is meaningful.

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 sentences with no wasted words: the purpose is front-loaded, the trigger condition comes second, and the audit-storage detail comes third. Every sentence adds distinct value and the structure is easy for an agent to parse.

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 plus fully documented schema gives the agent the trigger, the required inputs, and the side-effect of private audit storage. No output schema exists, but for a storage/audit action this is less critical. Minor omissions like return confirmation or permission requirements keep it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents command, agent_id, reasoning, and matched_rules. The description adds context about reasoning length and the relationship to guardrail_check, but it does not need to enrich parameters further; baseline 3 is appropriate.

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

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

The description uses a specific verb ('Record') with a clear object ('guardrail override') and states the exact purpose: documenting an override when a blocked action is explicitly authorized. It also differentiates from the sibling guardrail_check by framing this as the action to take after guardrail_check returns 'block'.

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

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

It explicitly states when to use the tool: 'Required when guardrail_check returns 'block' but the action is explicitly authorized.' This is a precise, actionable trigger condition that also references the sibling tool, leaving no ambiguity about the tool’s context.

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. 'Check' signals a read-only diagnostic action, which is useful, but the description does not disclose what the tool returns, how it behaves if unhealthy, or any side effects. This is minimal but sufficient for a simple health probe.

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 contains everything: action, resource, and condition. There is no filler, repetition, or unnecessary detail.

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 health check, the description states the single responsibility clearly. However, because there is no output schema, it leaves the exact return shape implicit; an agent must infer whether the response is a boolean, status object, or 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?

The tool has zero parameters, so the baseline is 4 and there is no parameter detail the description needs to add. The empty input schema and 100% schema coverage fully address this dimension.

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, 'Check', and identifies the exact resource, 'Nexus Memory', along with the target state 'running and healthy'. This clearly distinguishes it from all sibling tools, which perform other operations such as recall, update, or backup.

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 a diagnostic/preflight use case, but it does not explicitly say when to call this tool versus alternatives or when not to use it. There is no mention of prerequisites or timing, leaving usage 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 present, the description carries the full burden. It accurately signals a read-only listing behavior and discloses the returned fields, but it does not mention potential edge cases such as empty results, ordering, authentication requirements, or pagination 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?

One tightly scoped sentence states the action, the resource, and the return fields with no wasted words. The most important 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 zero-parameter, read-only listing tool, the description is essentially complete: it names the resource, the scope, and the fields returned. Minor omissions like response container format and error behavior do not meaningfully impair 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?

The input schema has zero parameters, so the baseline is 4 per the rubric. The description appropriately adds no parameter-level details because there are none to document.

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') and a specific resource ('currently registered webhook subscriptions'), and enumerates the exact fields returned. It clearly distinguishes the read-only listing role from mutation siblings like subscribe and unsubscribe.

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 'currently registered' makes the intended use clear: retrieve the existing set of webhook subscriptions. It does not explicitly name alternatives or exclusion conditions, but for a zero-parameter listing tool the context is unmistakable.

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. 'Search' and 'Returns' imply a read-only retrieval operation, but the description does not mention default validity filtering, access-level behavior, or whether results are ranked.

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 with no filler. The core action is front-loaded and the second sentence adds a scoping detail ('past sessions') without redundancy.

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

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

The description is adequate for a simple search tool, but it leaves important context implicit: what counts as a 'memory', how results are ordered/scored, and what the return payload looks like. With no output schema and no annotations, the description could reasonably say more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all four parameters and their meanings. The description adds no parameter-level detail, so the baseline of 3 applies.

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

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

The description states a specific action ('Search memories') and clarifies the resource and scope ('relevant context from past sessions'). It is clear enough to distinguish recall from write-oriented siblings like remember or forget, though it does not 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?

The intended use is implied: call this tool when you need to retrieve relevant past context. However, it gives no explicit guidance on when to prefer recall over related retrieval tools such as fact_history, find_entities, or graph_traverse.

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 burden. It discloses persistence across sessions, which is a key behavioral trait. However, it doesn't mention side effects like overwriting existing memories, deduplication, or that scoped memories are excluded from other agents' auto-prefetch (though the schema covers scope semantics). The description adds some value but not deep behavioral 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?

Two short sentences, front-loaded with the core action. No wasted words. It could add a bit more context, but it's appropriately concise.

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

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

For a write tool with 8 parameters and no output schema, the description is minimal. The schema covers parameters, but the description doesn't explain return behavior, error cases, or how this interacts with recall/forget. Given the tool's complexity (8 params, scoping, provenance), a bit more context would help, but the schema fills many gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no parameter-level meaning beyond 'store a memory'. Baseline 3 is appropriate since 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?

The description states a clear verb and resource: 'Store a memory for AI agents. Persists information across sessions.' This distinguishes it from recall/forget siblings. However, it doesn't explicitly contrast with update or fact_history, so it's clear but not fully differentiated.

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: use this to persist information across sessions. It doesn't explicitly state when to use this vs recall/forget/update, nor when not to use it. The schema provides some context (e.g., scope affects auto-prefetch), but the description itself lacks explicit routing guidance.

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

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

The description usefully discloses cost behavior (zero API cost by default) and the reembedding path. However, with no annotations present, it leaves an important gap: it does not state whether restoring overwrites, merges with, or clears existing memories, nor any side effects of the restore operation.

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, each earning its place. The core action is front-loaded, and the optional behavior is explained immediately after, with zero 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?

Adequate for invoking the tool with its two parameters, given full schema coverage and no output schema. However, the missing description of whether existing memories are replaced or preserved is a meaningful gap for a state-changing restore operation.

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 parameters are already documented. The description adds value by explaining the practical implication of reembed=true ('for provider changes') and the cost difference, which the schema does not convey.

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: restore memories from a backup JSON file. This clearly distinguishes it from sibling tools like backup, remember, and recall, and the difference from 'backup' is immediately inferable.

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

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

Provides clear guidance on the default behavior (reuse stored vectors) and when to override it (set reembed=true for provider changes). It does not explicitly mention alternatives, but the context is sufficient for correct use.

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 transparently states that subscriptions persist in ~/.nexus-webhooks.json and survive server restarts, and that the tool returns a UUID needed for unsubscribing. It does not mention duplicate-subscription handling or authorization requirements, but the core side effects are clearly 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?

Three sentences, each carrying unique information: the registration action, the return value, and the persistence behavior. The description is front-loaded with the main purpose and contains 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?

The tool is simple with two parameters, a full schema, and no output schema. The description covers the return value and persistence behavior, which are the main non-schema facts needed to call it correctly. Minor gaps remain around failure modes and duplicate subscription behavior, but they do not block correct usage.

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 describes both parameters completely, so the baseline is 3. The description adds useful context about the webhook receiving HTTP POST notifications and the returned subscription ID, but it does not add substantial parameter-level meaning beyond what the schema already provides.

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

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

The description uses a specific verb-resource pair: 'Register a webhook URL' to receive notifications for a specified memory event. It clearly differentiates this from sibling tools like unsubscribe and list_subscriptions by framing it as the subscription-creation operation.

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

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

The description implies the intended use case—registering a webhook to receive memory event notifications—but it does not explicitly state when to choose this tool over alternatives. The line 'which you need to unsubscribe' hints at the counterpart tool but does not provide explicit when-to-use versus when-not-to-use guidance.

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

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

With no annotations, the description carries the behavioral disclosure burden. 'Remove' clearly signals a destructive mutation, and 'returned from subscribe' provides a precondition, but the description does not disclose idempotency, error behavior for unknown ids, or side effects beyond the removal itself.

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 with no filler; the action, resource, and id provenance are front-loaded and each word earns its place.

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

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

For a simple one-parameter destructive operation with no output schema, the description provides the essential call information: what to do and which id to use. It does not document response or error shape, but the tool's low complexity makes the missing detail a minor gap.

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 schema already documents subscription_id. The description adds value by identifying the id as one returned from subscribe, which helps an agent know where to obtain it.

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 precise verb ('Remove'), the exact resource ('webhook subscription'), and the selection mechanism ('by its id'). It also distinguishes the tool from siblings like subscribe and list_subscriptions by making the destructive action explicit.

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 'returned from subscribe' gives clear context about where the id comes from and implies this tool is used after a subscription has been created. It does not explicitly list when-not-to-use or name alternatives, so it misses the top score, but the usage context 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?

The phrase 'in-place without losing metadata' adds a meaningful behavioral trait beyond the tool name. However, with no annotations, the description still does not disclose side effects, permissions, or how the operation handles optional fields like 'effective_from' or 'modified_by'.

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. Every phrase—'existing memory,' 'in-place,' 'without losing metadata'—adds relevant 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?

The schema fully documents parameters, but the description itself lacks usage guidance relative to the update-family siblings and provides only minimal behavioral context. It is minimally viable but leaves clear gaps for an agent deciding between this tool and alternatives.

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 are already documented in the input schema. The description adds no parameter-specific meaning, which is acceptable per the baseline when the schema handles it.

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, 'Update an existing memory in-place without losing metadata,' clearly indicating what the tool does. It gestures at a distinguishing behavior but does not explicitly differentiate from sibling tools like 'check_update' or 'do_update'.

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 given on when to use this tool versus related siblings such as 'check_update' or 'do_update'. The only usage signal is the implicit 'use it to update memories,' with no exclusions, prerequisites, or alternative routing.

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