MemoryGuard

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

With no annotations, the description discloses the important behavior: it writes to shared memory and records a DecisionEvent with action=accept_extract. This is explicit mutation disclosure beyond the verb 'accept', though it does not cover permissions, reversibility, or failure 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?

Two sentences with no filler: the first states the action and effect, the second states the required inputs. It is front-loaded and every clause contributes.

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 mutating tool with no annotations and no output schema, the description covers the main effect, the recorded event, and the required inputs. It leaves return values and failure modes unspecified, but the schema covers parameter details well.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description restates the extract_id prerequisite and adds the qualifier 'explicit' to candidate_ids, but provides only slightly more meaning than the schema.

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

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

The description names a specific action ('Accept extracted memory candidates'), the mechanism ('through GovernanceEngine'), and the concrete outcome ('write them to shared memory' plus a DecisionEvent). This clearly distinguishes the tool from generic memory_write or the extract_memories preview 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?

The description gives a clear precondition: extract_id must come from a prior extract_memories call and candidate_ids must be explicitly provided. This implies the intended workflow phase, though it does not explicitly name alternative tools to exclude.

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 explaining behavior. It implies a write to the V2 memory plane and gives one useful behavioral cue: the graph is refreshed by a subsequent build_and_enrich call. However, it does not disclose whether the operation is idempotent, reversible, or what happens to pending tasks after application, leaving meaningful ambiguity.

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 filler. The main purpose is front-loaded, the result shape is compressed into one clause, and the workflow instruction is immediately actionable.

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 rich schema and workflow context, the description is usable for invoking the tool: it identifies the data shape and the required follow-up step. However, with no output schema and no annotations, it leaves open important details such as return behavior, failure modes, and the exact effect on pending tasks or memory entries.

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's field list (task_id, kind, title, body, confidence) mostly mirrors the schema without adding deeper meaning. There is also a minor mismatch: it says each result includes confidence, while the schema marks confidence as optional.

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: "Apply host-agent enrichment results to the V2 memory plane." It also places the tool within a workflow by naming build_and_enrich as the follow-up step, which helps distinguish it from sibling extraction/acceptance tools. It does not sharply contrast itself against all similar siblings, but the purpose is clear and not tautological.

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 usage context: "After YOU enrich pending tasks, call this then memoryguard_build_and_enrich again to refresh the graph." This tells the agent when in the workflow to invoke the tool and what to do next. It does not describe when not to use it or mention alternatives, but the workflow guidance is strong.

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

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

With no annotations, the description carries the full burden and discloses meaningful behavioral traits: read-only operation, no network access, no writes, and findings-with-evidence output. This gives an agent confidence about side effects beyond what the schema alone provides.

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 dense sentences with zero filler. The core safety property ('Read-only scan') is front-loaded, followed by scope, output, and constraints. 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-optional-parameter audit tool, this is complete: it covers what is scanned, what is returned, and the side-effect profile. No output schema exists, but the high-level return description is adequate for selecting and invoking the tool.

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

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

The schema already documents the single optional 'workspace' parameter with 100% coverage, including its default value. The description adds no parameter-level detail, but the schema is sufficient, 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?

States a specific verb ('scan') and resource ('Agent workspace'), enumerates what is scanned (instructions, skills, memory, local RAG), and specifies the output ('findings with evidence'). The read-only framing clearly separates it from the many write-oriented memoryguard 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?

Provides clear context: this is a read-only audit scan of the local workspace, and the explicit 'No network, no writes' makes it obvious when it is safe to use. It does not name specific sibling alternatives or give when-not-to-use conditions, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It clearly discloses that this creates an active AgentBinding record, and explains that undo goes through CLI/GUI. It does not mention idempotency or return behavior, but the core mutation 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?

Two sentences, no filler. The primary action and effect are front-loaded, and the routing guidance is compact and directly useful.

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 create operation with fully documented parameters, the description covers purpose, effect, and alternative paths. It lacks explicit return/output details, but no output schema exists and the agent can verify through binding_list.

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 parameters are already well documented. The description adds no additional parameter-level detail beyond what the schema provides, so the 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?

States a specific action ('Bind an agent instance to a share_group') and its effect ('Creates an AgentBinding record (active)'), and explicitly differentiates from binding_list. The verb and resource are unambiguous and distinguish this from sibling tools.

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 routes read-only listing to binding_list and unbinding to CLI/GUI, making both when-to-use and when-not-to-use clear. This prevents an agent from attempting listing or unbinding with this tool.

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

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

No annotations are provided, so the description carries the full burden. It explicitly states 'Read-only,' which discloses the key behavioral trait of no mutation. However, it does not mention the default inclusion of inactive bindings, ordering, pagination, or output format, leaving some behavioral ambiguity.

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 at two short sentences, with no filler or redundancy. 'List existing AgentBinding records. Read-only.' is front-loaded and every word earns its place.

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

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

For a simple read-only list operation with two optional parameters fully described in the schema, the description is mostly complete. It clearly states the tool's purpose and safety profile. The main gaps are the lack of alternative routing and no mention of the output shape, but these are minor for such a low-complexity tool.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the input schema. The description adds no additional parameter-level meaning, which is acceptable given the high schema coverage, but it also does not compensate for any missing context.

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 specific resource ('AgentBinding records'), clearly identifying the tool's function. 'Read-only' further disambiguates it from mutation tools like memoryguard_binding_create. It is easy for an agent to distinguish this from sibling tools without opening the schema.

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

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

The description states what the tool does but provides no guidance on when to use it versus alternatives. There is no mention of other list-type tools or any conditions that would make this tool the right choice. An agent is left to infer the use case from the name alone.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It does reveal an important behavioral trait: in host mode the calling LLM itself must perform classification and translation, and the tool may require a recursive call after apply_enrichments. It also warns 'Do not require a separate AI-整理 button', which is a useful anti-footgun note. However, it does not disclose whether the tool persists data, whether it is destructive, what side effects occur, or what the return value looks like — significant gaps in the absence of annotations.

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 four short sentences, front-loaded with the core action ('Build memory projection') followed by the default mode and conditional workflow. Every sentence adds operational value: default behavior, the enrichment loop, the CLI variant, and a UX guardrail. The only minor issue is the terse 'AI-整理' jargon, but there is no wasted wording.

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 provides a usable workflow but leaves clear gaps for a complex tool with 7 parameters, no annotations, and no output schema. It does not define what a memory projection is, does not explain the reconstructed vs native distinction in the 'mode' parameter, and does not describe the expected return value. The condition 'pending_tasks / host_action_required' is mentioned but not specified, and the recursive call is only partially explained. Adequate as a minimum viable description, but not complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains that enrich_mode=host means 'YOU are the LLM' and enrich_mode=cli uses a chosen Agent CLI, giving operational meaning to llm_cli and llm_agent. It also clarifies the default enrich_mode. It does not add value for mode, workspace, share_group_id, or agent_instance_id, but those are already described in the schema.

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

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

The description opens with 'Build memory projection', a specific verb + resource, and the workflow ('call apply_enrichments, then call this again') positions it as the orchestration entry point, distinguishing it from sibling enrichment and projection tools. However, it never explains what a 'memory projection' is, and it does not explicitly differentiate itself from closely related siblings like memoryguard_apply_enrichments or memoryguard_projection_status.

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 conditional usage guidance: 'Default enrich_mode=host: YOU are the LLM' and 'Multi-agent GUI may pass enrich_mode=cli with a chosen Agent CLI', which tells the agent when host vs cli mode is appropriate. It also provides explicit chaining instructions — 'If pending_tasks / host_action_required, immediately classify+translate, call apply_enrichments, then call this again' — which is practical when-to-invoke guidance. It does not list exclusions or compare against sibling alternatives, 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 provided, the description carries the full behavioral burden. It explicitly declares the operation read-only and states it works under degraded governance, which is valuable. It also lists the output fields. It does not mention error behavior or whether the status is computed on demand, but for a read-only status check the disclosure is solid.

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

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

Two sentences with no filler. The key facts—read-only, target resource, output fields, availability guarantee—are packed efficiently and the most important scoping 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 two-parameter read-only tool with no output schema, the description covers purpose, output fields, and the special degraded-governance allowance. It lacks a fuller explanation of what 'canonical reconciliation' means or how this differs from projection_status, but the practical call context is sufficiently 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?

Schema description coverage is 100%, so both parameters are already documented with defaults. The description adds that share_group_id is the central entity but does not clarify how workspace or share_group_id interact, nor what the resolved binding default means. Baseline 3 is appropriate since the schema already handles the 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 identifies a read-only status resource for a share_group_id and enumerates the returned fields (canonical_ready, failures, checks, read_path). It does not explicitly contrast itself with sibling status tools like projection_status or memory_status, so it stops short of full differentiation, but the intent 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 statement 'Always allowed, even when governance is degraded' provides a concrete availability condition and implies this is the right tool when governance is impaired. However, it gives no guidance on when to prefer this over other status/read tools among the many siblings, nor any 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 full burden, but it only hints at 'bounded' and 'scoped' behavior. It does not disclose whether the call is read-only, what happens for an unknown start_id, how depth/limit interact, or what the returned metadata looks like.

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

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

The description is a single sentence with no filler, and the most important qualifiers are front-loaded. It is very concise, though its terseness contributes to the lack of behavioral and parameter guidance.

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 six parameters, no annotations, and no output schema, a one-line description is insufficient. It omits relation semantics, workspace/provenance scoping, and output expectations, which are necessary for reliable invocation.

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

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

Schema description coverage is 0%, and the description does not explain start_id, relation, workspace, provenance, depth, or limit. 'Bounded', 'reverse-impact', and 'scoped' give weak hints, but relation and provenance are the crucial parameters for determining what is returned, and they are left unexplained.

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

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

The description names a specific operation ('Return ... metadata') with a clear resource ('CodeGraph symbol') and adds distinguishing qualifiers: 'reverse-impact', 'bounded', and 'scoped'. This separates it from generic codegraph_query/path/explain operations by conveying the exact intent.

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 about when to use this tool versus siblings like memoryguard_codegraph_query or memoryguard_codegraph_path. The description only states what the tool does, leaving selection entirely 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It meaningfully discloses that the source map is metadata-only (not full source) and that edges are bounded, which informs agents about output scope and limits. It does not mention side effects, but 'explain' and 'metadata-only' strongly imply a read-only 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?

The entire description is a single, front-loaded sentence with no filler. It leads with the verb and resource, then adds two precise qualifiers. 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 no annotations, no output schema, and four parameters at 0% schema documentation, the description is too terse to be fully actionable. It never explains what the returned metadata-only source map looks like, what provenance options mean, or what happens when edge_limit is reached. A tool with this complexity and no structured context needs more behavioral and parameter detail.

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 implicitly maps 'one scoped CodeGraph symbol' to symbol_id and workspace, and 'bounded edges' to edge_limit, but it does not explain workspace syntax, provenance filtering, or how edge_limit interacts with the output. It adds some value over the bare schema but leaves two parameters effectively undocumented.

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 ('Explain'), a specific resource ('one scoped CodeGraph symbol'), and two distinct qualifiers ('metadata-only source map' and 'bounded edges') that differentiate it from broader alternatives like memoryguard_explain or other codegraph traversal tools. An agent can identify what this tool is for without opening the schema.

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

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

The description implies a use case: explaining a single, scoped symbol in the CodeGraph with metadata only and bounded edges. However, it does not explicitly name alternatives or state when not to use it, such as when full source is needed or when querying multiple symbols. With many sibling tools, some explicit routing would be valuable.

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 state that the result is a single bounded directed path and that direction matters, but it does not explain what 'bounded' means in practice, what happens if no path exists, or any scoping or side-effect behavior. The edge cases and operational behavior are undocumented.

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 sentence of 11 words, front-loaded with the core operation and its key constraint. There is no filler or repetition, and the essential purpose is immediately visible.

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 6-parameter tool with no output schema, no annotations, and 0% schema description coverage, so the description is the only source of guidance beyond raw parameter names. It does not cover parameter semantics, no-path behavior, return shape, or how workspace/provenance scoping affects results. The description is too thin to fully support correct invocation in non-trivial 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. It loosely identifies 'two scoped CodeGraph symbols', which maps to start_id and end_id, but it says nothing about relation, max_depth, workspace, or provenance semantics. Since max_depth and relation are likely central to path binding, this is a significant 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 uses a specific verb ('Find') and a precise object: 'one bounded directed path between two scoped CodeGraph symbols'. This clearly distinguishes the tool from sibling codegraph query/explain/affected/update/status operations because it targets a path-finding result. It does not explicitly name a sibling, but the resource and behavior are 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 implies the tool should be used when an agent needs a directed path between two symbols in the CodeGraph. However, it gives no explicit guidance about when to prefer this over memoryguard_codegraph_query or memoryguard_codegraph_explain, and it does not name alternatives or exclusions. Routing is left mostly to the agent's 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 behavioral burden. It clearly signals that this is a read-only query operation and states an important guarantee: 'Source bodies are never returned.' This is valuable beyond the schema, though it leaves out other behavioral details like result shape or scoping 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?

The description is two short sentences with no filler. The main action is front-loaded, and the second sentence adds a meaningful limitation. Every word earns its place.

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

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

For a tool with four parameters, no annotations, no output schema, and several closely related siblings, this description is too sparse. An agent would not know the query syntax, how workspace and provenance affect results, whether limits apply to matches, or when to choose this over codegraph_explain or codegraph_path.

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

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

Schema description coverage is 0%, so the description should compensate for the four parameters. It only gives general context ('scoped CodeGraph symbol metadata') and never explains what the 'query' string expects, how 'limit' behaves, what 'workspace' scopes, or the meaning of 'provenance.' The parameter names and enum help slightly, but the description adds little beyond the schema 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 states a specific verb ('Query'), a resource ('CodeGraph symbol metadata'), and narrows the scope ('scoped'). It is clear enough to distinguish from codegraph_path, codegraph_affected, or codegraph_status, though it does not explicitly name the sibling it competes with.

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

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

No guidance is given for when to use this tool versus the many sibling tools such as memoryguard_codegraph_path, memoryguard_codegraph_affected, or memoryguard_codegraph_explain. The word 'scoped' hints at a use context, but there is no explicit when-to-use or when-not-to-use direction.

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 bears the full burden. It adds a useful limitation ('without claiming production readiness') and notes the report is 'scoped,' but it does not disclose whether the operation is read-only, how capability is determined, or what failure modes exist.

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 sentence with no filler. The action and object are front-loaded, and the production-readiness caveat is an efficient, purposeful addition.

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 low-complexity tool with one optional parameter and no output schema, the description communicates the core purpose and a key limitation. However, it does not describe the return format, how 'capability' is represented, or when this tool should be preferred over related status 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. 'Scoped' suggests the workspace parameter controls the scope of the counts, adding partial meaning. However, it does not explicitly connect 'workspace' to the scoping behavior or explain optionality/defaults, though there is only one optional parameter.

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

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

The description uses a specific verb ('Report') and names a concrete resource ('scoped CodeGraph counts and Graphify metadata-export capability'). It clearly distinguishes this as a status/capability tool rather than a query or mutation tool, though it does not explicitly contrast with sibling tools.

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 use this tool versus the many sibling status/query tools. The purpose implies usage, but no alternatives, exclusions, or triggering conditions are 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does reveal that source bodies are rejected, indicating metadata-only ingestion, but it is silent on side effects such as overwriting, appending, deleting existing storage, or requiring confirmation beyond the schema. This is thin for an update/import 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?

The description is two short sentences with no filler, and the key caveat is placed prominently. It is efficient and front-loaded, though the dense terminology slightly reduces clarity.

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

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

For a 4-parameter tool with no output schema and no annotations, a single-sentence description is not enough. It omits the meaning and required behavior of 'confirmed', the effect of 'full_snapshot', and what happens to existing CodeGraph storage, so an agent cannot fully anticipate the tool's behavior.

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 only adds meaning to the 'export' parameter by calling it a metadata export and stating source bodies are rejected. The required 'confirmed' parameter and the meaningful 'full_snapshot' parameter are completely unexplained, which is a significant gap for an agent trying to invoke the tool correctly.

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 concrete action: projecting a trusted MemoryGuard Graphify Core metadata export into scoped CodeGraph storage, and adds a distinguishing constraint: 'Source bodies are rejected.' Though 'Project' and 'Graphify Core' are somewhat jargon-heavy, the core action is clear and distinguishable from sibling codegraph query/status tools.

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: when an agent has a trusted Graphify Core metadata export and wants to load it into CodeGraph storage. It also signals that source bodies are not appropriate input. However, it does not explicitly contrast this tool with alternatives or state when not to use it.

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

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

No annotations are present, so the description carries the burden of behavior disclosure. It explicitly states read-only behavior, reliance on the trusted MCP identity/binding, inclusion/exclusion rules (active preferences, governed memories, sensitive/unsafe states omitted), and non-interference with the conversation. This is strong transparency, though details like error cases or behavior on missing bindings are not covered.

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 dense sentence front-loads the main purpose and then enumerates key constraints efficiently. No redundant or filler content.

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 6-parameter tool with no annotations and no output schema, the description gives strong high-level context but omits the purpose of budget parameters and the shape of the returned packet. An agent could invoke it based on the required task parameter, but optional-parameter decisions would rely entirely on the schema, which is incomplete for two parameters.

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 description adds no parameter-level meaning; schema coverage is 67%, leaving max_chars and max_items without descriptions in either schema or tool text. The word 'bounded' only indirectly hints at the budget parameters and does not explain their meaning or relationships.

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

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

Clear verb-resource pairing: 'Build one bounded, read-only long-term-memory context packet for a new task.' It is obviously not a raw memory read or write, but it does not explicitly contrast itself with sibling read/search tools, so the differentiation is implicit rather than 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?

States the trigger condition 'for a new task' and a non-goal ('never replaces or repeats the host's current conversation'), giving the agent a clear context for use. It does not name alternatives or explicitly say when not to use other memory tools.

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

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

With no annotations, the description carries full behavioral burden and does an excellent job: it discloses read-only behavior, the sqlite3 backup mechanism, that DB/WAL files are never copied, that arbitrary SQL and file paths are rejected, and that the tool is always allowed. This gives an agent a clear safety profile.

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 deliver purpose, output contents, safety behavior, and availability without redundancy. The most important scoping fact (read-only diagnostics snapshot) 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?

Given no output schema, the description still names the JSON sections the agent can expect. With only two optional params fully documented in the schema and safety/availability clearly covered, nothing essential for calling or interpreting this tool is missing.

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

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

Schema coverage is 100% and both optional parameters already have descriptions with defaults, so the baseline applies. The description does not add additional meaning about workspace or share_group_id, but neither is it required given the complete schema coverage.

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

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

The description is specific: it states this is a read-only governance diagnostics snapshot and enumerates the exact content areas (reconciliation jobs by status, canonical activation, projection, source links, bindings). This clearly separates it from the many memory, history, binding, and codegraph 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?

'Always allowed, even when governance is degraded' gives a clear context for when this diagnostic can be run, and the read-only/SQL-free constraints signal safe use. It does not explicitly name alternatives or when-not-to-use conditions, but the use context is strong.

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 burden. It communicates that the tool reads queue status and returns pending/applied counts, and it adds useful context about the residual-enrichment role. However, it does not explicitly state that the operation is read-only, describe the response shape, or mention any potential limitations or 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 two compact sentences with no filler. The main action and output are front-loaded, and the second sentence adds valuable routing context 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?

For a relatively simple status-check tool with three optional, fully documented parameters and no output schema, the description is largely complete: it explains what counts are exposed and how the tool fits into the enrichment lifecycle. It could have elaborated on how this differs from similar enrichment-related siblings, but that is not a blocking 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 description coverage is 100%, and the description adds no parameter-specific meaning beyond what the schema already provides. The schema already documents workspace, share_group_id, and agent_instance_id with clear semantics, so the baseline 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 states a specific action ('Check'), a clear resource ('enrichment queue status'), and the precise output ('pending/applied counts'). It also differentiates itself from build_projection by positioning this tool as the residual-status companion rather than the primary enrichment path.

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 notes that primary enrichment happens inside build_projection and that this tool should be used to see residuals, giving the agent a clear when-to-use signal. It does not explicitly mention sibling tools like list_pending_enrichments or apply_enrichments, so it stops short of fully routing among all alternatives.

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

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

With no annotations, the description carries the full burden, but 'explain' strongly implies a read-only action and the listed output fields give an idea of what the tool returns. It does not explicitly state that no state is modified, nor does it mention any prerequisites or error behavior, which prevents a higher score.

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 that conveys the tool's core purpose and the relevant output dimensions without excess words 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 simple read/explain tool, the description is largely complete: it names the resource, the action, and the expected explanatory fields. It does not explicitly clarify the source of the finding or the relationship to the audit workflow, but the schema's finding_id description covers the key input requirement.

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 finding_id and workspace already documented in the schema. The description adds no parameter-level meaning 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 verb ('explain') and a clear resource ('a finding'), and lists the exact content it covers: evidence, impact, suggestion, and confidence. It is distinguishable from siblings like codegraph_explain, though it does not explicitly say the finding comes from the audit 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?

The description implies the tool is used when you have a finding_id and want to understand its evidence, impact, suggestion, or confidence. It does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as reading the finding directly or using codegraph_explain.

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 full responsibility for behavioral disclosure. It meaningfully reveals that the operation classifies (L0-L4), persists the descriptor, returns a detection result, and avoids live server calls. This goes beyond a generic 'import' and gives the agent an accurate mental model of side effects and scope, though it omits details like overwrite behavior or error 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?

Three tightly written sentences: the primary action and inputs in the first, the processing steps and return value in the second, and a crucial scope clarification in the third. Every sentence adds distinct information, with no filler or repetition of schema contents.

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

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

The description covers the essential context for a single-required-parameter tool: what is imported, what processing occurs, what is returned, and the critical boundary (no live server call). It lacks return-format details and explicit relationship to nearby import/preview tools, but given the schema completeness and the tool's modest complexity, it is sufficiently complete 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?

Schema description coverage is 100%, so all three parameters are already documented with names and descriptions. The tool description does not add parameter-specific semantics beyond reiterating that the input is descriptor JSON and that import is descriptor-level, which is already captured by the schema's descriptor_json description. This meets the baseline but does not elevate 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 specific verb ('Import'), a specific resource ('external MCP descriptor (JSON)'), and the concrete outcomes: classifies the server (L0-L4), persists it, and returns the detection result. It also distinguishes itself from live MCP invocation with 'descriptor-level import only; does not call the live MCP server,' making the tool's role unmistakable among 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?

The description provides clear context for when this tool is appropriate: importing descriptor-level JSON only, and explicitly says it does not call the live MCP server. However, it does not name alternative tools (e.g., import_preview or external_mcp_list) or give conditions for choosing them over this tool, so it falls short of full 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?

No annotations are provided, so the description carries the full burden. It explicitly discloses 'Read-only', which is crucial for an agent assessing side effects, and further clarifies that no live MCP client discovery occurs. This is strong behavioral context for a simple listing 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 two short sentences with no filler. It front-loads the core action and resource, then immediately provides the key scope caveat. 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 tool's simplicity—one optional parameter, no output schema, read-only behavior—the description is complete. It states what is listed, the level of detail, and the behavioral boundary, so an agent has enough information 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 input schema already documents the single optional workspace parameter at 100% coverage with the description 'workspace path (default: .)'. The tool description adds no additional parameter semantics, 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 verb ('List') and names the exact resource ('imported external MCP server descriptors and their resources'). It also clarifies the scope with 'Descriptor-level only', making it distinct from live-discovery tools and from the sibling import 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?

The description provides clear context by stating that this is descriptor-level and explicitly excludes live MCP client discovery. This tells the agent what the tool will not do, though it does not explicitly name an alternative tool or state a direct when-to-use condition.

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, and it delivers: 'read-only preview' and 'Does NOT write to shared memory' explicitly disclose non-mutation, and 'authorized source root' signals permission constraints. It could add detail on error behavior for unauthorized paths or file-size limits, but the safety profile is clearly conveyed beyond what structured fields provide.

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 zero waste: purpose and scope, return shape, then the non-write declaration and sibling routing. The primary verb and resource are front-loaded, and every sentence earns its place by conveying information not available elsewhere in the structured data.

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 output schema and no annotations, the description covers the key gaps: what it returns (kind, risk_level, preview), that it is non-destructive, and what the follow-up tool is. Minor gaps remain—preconditions like whether the source must already be registered, and error behavior for unauthorized paths—but the essentials an agent needs to call it correctly are present.

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 marginally reinforces source_path semantics by repeating the 'authorized source root' constraint, but it adds no new meaning for either parameter beyond what the schema already documents. There is no genuine compensation needed or provided.

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

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

The description states a specific verb+resource: 'Extract memory segments from a source file under an authorized source root.' It also describes the return value (candidate list with kind, risk_level, preview) and explicitly differentiates itself from siblings by declaring 'Does NOT write to shared memory' and pointing to memoryguard_accept_candidates for the write path. An agent can distinguish this from the 50+ siblings without opening the schema.

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

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

The description provides clear context ('read-only preview') and explicitly routes to an alternative: 'Use memoryguard_accept_candidates to write accepted candidates.' This names a sibling and the condition selecting it. However, it lacks explicit when-not-to-use guidance or differentiation from other preview-like siblings (e.g., memoryguard_import_preview, memoryguard_history_extract_preview), so it stops short of a 5.

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

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

There are no annotations, so the description carries the safety burden. It discloses that deletion is permanent, that confirmation is required, and that long-term memories are not affected. However, it does not explain side effects of invalidate_evidence or whether related evidence/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?

Two brief sentences with the action and resource front-loaded, followed by the guardrail and memory boundary. No filler, but the phrase 'for the trusted Agent' is slightly ambiguous and costs a 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?

For a destructive four-parameter tool with no output schema and no annotations, the description omits meaning for two parameters, does not state what a successful delete returns, and gives no pointer to history_list_sessions for obtaining session IDs. The safety boundary is clear, but safe invocation needs 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?

With schema description coverage at 0%, the description is the only semantic source. It covers confirmed (requires true) and session_ids (implicitly the explicitly selected sessions), but leaves scope and invalidate_evidence completely unexplained; the schema has no property descriptions to compensate.

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: 'Permanently delete ... raw-history sessions.' It also adds 'never deletes long-term memories,' which clearly separates it from the memory_delete sibling, so an agent can distinguish the tool without opening 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?

It gives a clear usage context (deleting explicitly selected raw-history sessions) and a precondition ('Requires confirmed=true'), plus a boundary ('never deletes long-term memories'). It does not explicitly name the alternative memoryguard_memory_delete or cover when to favor other history tools, so it falls just short of full guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that the export concerns raw history rather than memory, but does not disclose output format, whether a file is produced, side effects, permissions, or whether the operation is read-only. This is a meaningful transparency gap for an export 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 two short sentences with no filler. The first sentence delivers the core action and constraints, and the second adds a meaningful distinction that helps prevent misuse by steering the agent away from long-term memory concepts.

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

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

Given no annotations, no output schema, and 0% schema description coverage, the description leaves important operational context missing. An agent cannot tell what the export returns, how the output is delivered, what scope means, or how session_ids should be obtained and passed. The description is too thin for a tool with these 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 0%, so the description must compensate for documenting parameters. 'Explicitly selected sessions' loosely maps to session_ids, but the optional scope object is entirely unexplained. The description adds minimal semantic value beyond the array property name and fails to clarify how session_ids should be formatted or what scope controls.

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 identifies the operation as exporting explicitly selected sessions, which is a specific verb and resource. It further distinguishes the tool from memory-related siblings by stating 'This is raw-history evidence, not long-term memory.' It does not explicitly name a sibling alternative, but the verb and scope make the purpose 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 implies when to use the tool: when raw-history evidence from explicitly selected sessions is needed, rather than long-term memory. It provides a useful exclusion ('not long-term memory') but gives no explicit guidance about when to prefer history_read, history_search, or history_list_sessions 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?

No annotations are provided, so the description carries the full burden. 'Read surface' hints at a read-only operation but provides no details about side effects, data scope, output, or limitations. This is insufficient behavioral disclosure.

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 short, but this is under-specification rather than conciseness. It contains a single vague phrase that fails to convey the tool's purpose.

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

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

With no annotations, no output schema, and no parameter info, the description is the only source of context. It is completely inadequate for an agent to understand, select, or invoke this 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 is an empty object with 0 parameters, so the baseline is 4. The description doesn't need to explain parameter semantics because there are none.

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 'V2-native read surface' does not state a concrete action or resource. It gives no indication that this tool previews history extraction, making the purpose effectively missing. The tool name hints at the function, but the description itself fails to communicate it.

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 any of the many siblings. It also doesn't mention any exclusions or alternatives. The description provides zero context for decision-making.

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 safety and behavior. It explicitly states the operation is read-only and that raw text is not returned, which are important behavioral disclosures. However, it does not mention pagination, output shape, or any other behavioral constraints.

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 that conveys the core purpose and a key limitation without any filler. 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?

This is a six-parameter tool with 0% schema coverage and no output schema, yet the description only provides a high-level summary. It does not explain parameter semantics, filtering behavior, response format, or how this listing relates to other history tools. Substantial additional detail is needed for correct invocation.

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

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

Schema description coverage is 0%, and the description adds no meaning to any of the six parameters (limit, scope, offset, date_to, date_from, extracted). The description's job is to compensate for the blank schema, but it completely fails to do so.

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 operation: listing the trusted Agent's local conversation-history sessions. It also adds the distinguishing note that raw text is not returned, which helps separate it from history_read and history_search, though it does not explicitly name those 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?

The description provides no explicit guidance on when to use this tool versus siblings like history_search, history_read, or history_timeline. The phrase 'raw text is not returned' implies it is for metadata-level listing, but there is no direct 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. 'Read surface' does indicate a read-only operation, but it does not explain what is read, what is returned, whether any state is observed globally, or how this maps to a V2-native API. This is only marginally more informative than the tool name 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?

The description is only four words, so it is short, but it is short by omitting almost all necessary substance. This is under-specification rather than efficient, front-loaded communication.

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, no annotations, and an extremely broad sibling set, this description is far from complete. It does not state what the read surface returns, how it relates to the history family, or what distinguishes it from memory_read and knowledge_read. An agent cannot confidently predict the invocation result.

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 description coverage is 100%, so the baseline is 4. There is no parameter meaning for the description to add beyond the empty schema.

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

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

The description only says 'V2-native read surface', which is a vague genre label rather than a specific verb+resource statement. It relies entirely on the tool name to imply that history data is being read, and does not say what history entity or scope is involved. It is closer to a tautology than to a usable 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?

No guidance is given about when to use this tool versus the many sibling history tools such as history_search, history_timeline, history_list_sessions, or memory_read. With dozens of siblings, the absence of any routing or selection context leaves the agent to guess.

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

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

With no annotations, the description carries the full behavioral burden. 'Read surface' hints at non-mutating behavior, but nothing is disclosed about output shape, filtering, pagination, or side effects. This is minimal at best.

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 short with no wasted words, but it is under-specified to the point of being cryptic. Conciseness should complement information, not replace it.

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 search tool with no output schema, the description should explain what is being read or returned. 'V2-native read surface' provides no actionable detail about the operation or its results, making it inadequate even for a parameterless tool.

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

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

The tool has zero parameters and 100% schema description coverage, so the description does not need to explain parameters. The score reflects the baseline for a parameterless tool.

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 'V2-native read surface' is vague and does not state a concrete verb or resource. It does not mention searching, history, or what data is surfaced, leaving the agent to infer the tool's purpose from its name rather than the description.

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

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

There is no guidance about when to use this tool versus the many sibling history tools (e.g., history_timeline, history_read, memory_search). No context, conditions, or alternatives are 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. 'Read surface' implies read-only behavior, but it does not explain what a timeline contains, how results are returned, whether there is pagination, time-range filtering, or any other observable behavior. The disclosure is minimal.

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, but brevity here is under-specification rather than conciseness. The phrase 'V2-native read surface' contains a jargon term that is not defined and contributes no usable information. It does not earn its place in the definition.

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?

Despite having no parameters, the tool still lacks an output schema and has a highly ambiguous purpose. The description does not explain what the timeline is, how it relates to history tools, or what the agent should expect as a result. For a tool in a large sibling set, this is not enough context to select and 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 has zero parameters and the schema coverage is 100%, so there is no parameter documentation gap for the description to fill. The baseline of 4 applies because no parameters need explanation.

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 only 'V2-native read surface.' It indicates a read operation but never identifies the resource: 'history' and 'timeline' are absent, so the agent cannot tell what data this tool actually exposes. This is too vague to count as a clear purpose, though not a pure restatement of the name.

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 such as memoryguard_history_read, memoryguard_history_search, or memoryguard_history_list_sessions. No context, exclusions, or alternative tools are mentioned, leaving the selection decision entirely to the agent.

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

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

With no annotations provided, the description carries the full behavioral burden. It explicitly discloses a key behavioral trait—'Read-only'—and indicates what the tool does ('detection + inventory'). It does not detail output structure or edge cases, but the core safety behavior is clearly communicated.

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, front-loaded sentences with no filler. It states the action, the resource, the formats, and the read-only nature 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?

The description is adequate for tool selection and basic invocation, and the schema covers the parameters. However, there is no output schema, and the description does not clarify what the 'inventory' or 'detection' result looks like, which is reasonably important for a preview tool.

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

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

Schema description coverage is 100%, so the schema already documents both 'path' and 'workspace'. The description does not add meaningful parameter-level detail beyond the contextual note that bundles are ChatGPT/Claude/Gemini/Generic. 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 ('Preview') plus a clear resource ('offline import bundle') and names supported formats (ChatGPT/Claude/Gemini/Generic). The phrase 'Read-only detection + inventory' further clarifies it is a non-mutating inspection tool, distinguishing it from sibling import or extraction tools.

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 verb 'Preview' and 'Read-only' make the intended usage clear: inspect an offline bundle before committing to an import. It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for an agent to infer the right use case.

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 and no output schema, the description carries the full burden of behavioral disclosure. It does not state side effects, read/write behavior, permissions, output format, or any operational characteristics beyond the vague 'V2-native' label.

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, but it is under-specified rather than usefully concise. It front-loads jargon ('V2-native') and provides no actionable information, so the brevity does not help an agent select or invoke the tool.

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?

Even though the tool has no parameters, an agent has no idea what the tool returns, what action it performs, or how it relates to the many sibling knowledge tools. The definition is not minimally viable for correct tool selection.

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 is an empty object with zero parameters, so the baseline is 4 and no parameter documentation is needed. The description adds no parameter-specific meaning, but none is required.

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 'V2-native knowledge surface.' is effectively a synonym for the tool name 'knowledge_book' rather than a statement of what the tool does. It is a noun phrase with no verb, so an agent cannot tell whether this tool reads, writes, lists, or exposes knowledge.

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 or when to prefer related siblings such as memoryguard_knowledge_read, memoryguard_knowledge_list, or memoryguard_knowledge_search. No alternatives, exclusions, or context are mentioned.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior, side effects, or output characteristics. 'V2-native knowledge surface' discloses nothing about what the tool does, whether it reads or writes, or what an agent should expect from calling it.

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 but this is under-specification, not effective conciseness. The phrase 'V2-native knowledge surface' does not earn its place because it fails to convey meaning.

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

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

Even with no parameters and no output schema, the description must explain enough for an agent to decide whether to invoke the tool. A single vague phrase is severely inadequate, especially given the large set of sibling tools with overlapping 'knowledge' or 'candidate' naming.

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 there is no parameter semantic burden for the description to carry. The baseline of 4 applies because no additional parameter explanation is needed.

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 'V2-native knowledge surface' contains no verb or resource, and does not state what the tool does. It is an opaque label rather than an explanation, leaving the agent to guess whether the tool lists, generates, or manages candidates.

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

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

There is no guidance on when to use this tool or how it relates to siblings such as memoryguard_accept_candidates or memoryguard_knowledge_list. The description provides no context for selection, so the agent receives no usable direction.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals nothing about read-only behavior, return shape, pagination, scoping, or 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 short but is under-specification rather than effective conciseness: 'V2-native knowledge surface' does not earn its place as a standalone tool description.

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

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

With no annotations, no output schema, and an opaque one-line description, the tool is seriously under-documented even for a zero-parameter list operation. It lacks scoping, behavior, and relation to the many 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?

The input schema is an empty object and there are zero parameters, so there is no parameter information for the description to add. The baseline of 4 applies because no parameter documentation burden exists.

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, 'V2-native knowledge surface,' does not state what the tool does; it is a vague noun phrase with no verb such as list or retrieve. It does not distinguish knowledge_list from siblings like knowledge_search, knowledge_read, or knowledge_book.

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

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

There is no guidance on when to use this tool versus any of the many knowledge-related siblings, nor any exclusions or alternatives. An agent must infer usage entirely from the tool name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it discloses nothing: no read-only confirmation, no effects, no return format, no pagination or versioning behavior. The only hint of non-mutation is the verb 'read' in the tool name, which the description itself never confirms.

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 words is brief, but this is under-specification rather than disciplined conciseness. The phrase 'V2-native knowledge surface.' is jargon that does not earn its place — a short description only scores well when its few words actually inform, and these do not.

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

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

With no annotations and no output schema, the description is the agent's only source of context, and it provides essentially none. A read tool needs at minimum a statement of what is read and what is returned; 'V2-native knowledge surface.' is completely inadequate for that purpose.

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 0 parameters, so there is nothing for the description to document beyond the schema, which is trivially complete. Per the baseline for zero-parameter tools, this dimension is satisfied even though the description adds no parameter information.

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 'V2-native knowledge surface.' contains no verb and no concrete resource — 'surface' is an unexplained metaphor and 'V2-native' is a version tag, not a functional statement. The tool's actual behavior (reading knowledge) is only inferable from its name, and nothing distinguishes it from siblings like memoryguard_knowledge_list, memoryguard_knowledge_search, or memoryguard_memory_read.

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 invoke this tool versus any of its 60+ siblings. No context, no exclusions, no alternatives — an agent cannot determine whether knowledge_read, knowledge_search, knowledge_list, or memory_read is the right choice without opening other definitions.

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 and no output schema, the description carries the full burden of behavioral disclosure. It provides none: no mention of query behavior, scope, read-only nature, side effects, or return semantics.

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, but it is under-specified rather than usefully concise. 'V2-native knowledge surface' is a vague label that does not earn its place because it conveys no actionable 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 no annotations, no output schema, and no parameter constraints, the description is critically incomplete. An agent has no way to understand the tool's behavior, preconditions, or relationship to the dozens of 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?

The tool has zero parameters, so parameter semantics are vacuously satisfied. There is no need for the description to explain parameters that do not exist.

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 'V2-native knowledge surface' does not state any action, resource, or function. It restates only the 'knowledge' part of the tool name without indicating what 'search' does, and it does nothing to distinguish this tool from knowledge_list or knowledge_read.

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 any of its many siblings. No context, conditions, or alternative tools are mentioned.

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

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

With no annotations provided, the description carries the full behavioral burden. It implies a read-only listing operation and clarifies its position in the enrichment pipeline, but it does not explicitly state that the list call has no side effects, how 'pending' is determined, or what happens when there are no pending tasks.

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 core purpose is stated in one short, front-loaded sentence. The second sentence adds actionable workflow guidance and is slightly dense, but every clause contributes context needed for correct use.

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 list tool with fully documented parameters, the description provides enough context about why to call it and what to do next. It does not describe the response shape, but no output schema exists, and that omission is minor for a listing 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 description coverage is 100%, so the input schema already documents limit, workspace, share_group_id, and agent_instance_id. The description adds no parameter-level meaning beyond what the schema provides, so it meets but does not exceed 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 opens with a specific verb and resource: 'List pending memory enrichment tasks,' which clearly identifies both the action and the output. It also anchors the tool in a workflow ('after build_and_enrich returns host_action_required'), distinguishing it from related tools like apply_enrichments or enrichment_status.

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 clear condition for when the tool matters—after build_and_enrich signals host_action_required—and instructs the host agent to proceed with apply_enrichments instead of asking the user to choose a CLI. It does not explicitly name alternative tools to rule out, but the workflow context is strong enough for an agent to select this tool appropriately.

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 explicitly states 'Read-only,' which is a key behavioral trait, and clarifies the scope of what is listed. It is concise but sufficient for a simple read-only list 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?

The description is one short sentence and immediately states the action and scope. Every word adds value, and 'Read-only' is placed at the end without bloating the text.

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: one optional parameter, no output schema, and no nested structures. The description covers what the tool lists and that it is read-only. It does not describe the return format, but for a list operation this is not a significant 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 description coverage is 100%, and the parameter 'workspace' is already documented with type and default value. The description adds no additional parameter semantics, 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 names a specific verb ('List') and resource ('authorized sources'), and adds concrete examples (project directory, selected folders, Obsidian vaults) that distinguish it from other list-type sibling tools. This leaves no ambiguity about what the tool returns.

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 no explicit guidance on when to use this tool versus alternatives such as memoryguard_external_mcp_list or memoryguard_knowledge_list. 'Read-only' implies it is safe to call, but it does not state the conditions that should lead an agent to choose this tool.

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

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

With no annotations, the description carries the full burden. It wisely discloses that the operation is a soft delete and that it records a DecisionEvent, which are meaningful behavioral facts. Still, it does not describe side effects, reversibility, or behavior around idempotency/identity checks, so it is adequate 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 two short sentences with no filler. The primary action and state change are front-loaded, and the DecisionEvent note adds useful behavioral context without bloat.

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-required-parameter deletion tool, the description covers the essential effect (soft delete, status change, audit trail). There is no output schema, but the call is simple enough that the agent can proceed confidently with the schema plus this description. Some extra detail on idempotency behavior would help, but it is not essential.

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 explains `memory_id`, `idempotency_key`, and `agent_instance_id`. The description adds no parameter-level meaning, which matches the baseline score of 3 since the structured schema is doing 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 uses a specific verb ('Soft-delete') and resource ('memory record') and adds the resulting state (`status=deleted`), which clearly separates this from other history/binding tools. It is not a tautology and names the core action precisely.

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 this is the non-destructive deletion path by saying 'soft-delete', which gives some context about when to use it. However, it does not explicitly say when to prefer this over a hard delete or any alternative sibling tool, so the usage guidance remains 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, the description must carry the behavioral burden, and it does disclose meaningful traits: the operation is governed, admin-only, requires confirmation, and leaves owner update/delete unchanged. It does not, however, explain concrete effects such as what happens to the duplicate atom, whether the operation is reversible, or what the agent should expect in the response, which are significant for a mutating action.

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 tightly packed sentences with no filler. It front-loads the core action and scope, then adds governance context, confirmation requirement, and boundary constraints, with every sentence earning 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?

This is a complex mutating operation with nine parameters, nested objects, no annotations, and no output schema, yet the description omits the operational flow such as the preview step, how CAS revisions are used, and the effect on the duplicate atom. An agent can identify the tool's purpose but lacks enough context to confidently execute the full transaction end to end.

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 78%, and most parameters already have meaningful descriptions such as 'CAS map' and 'native mutation receipt'. The description only adds the confirmed=true requirement, so it contributes little 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 names a specific verb ('supersede'), a specific resource ('duplicate memory atom' into 'canonical atom'), and scope ('same-group'), which clearly distinguishes it from generic memory operations. It does not explicitly name sibling tools like memoryguard_memory_merge_safe_preview or memoryguard_rule_merge_safe, so differentiation is evident from context rather than directly stated.

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 important preconditions: admin-only access, confirmed=true required, and no force or bypass. However, it does not explicitly say when to use this tool versus alternatives such as the preview tool or rule-based merge, leaving the agent to infer selection logic from tool names and surrounding 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 provided, the description fully carries the behavioral disclosure burden and does so explicitly: 'does not write transactions, decisions, undo, or idempotency records' and 'There is no force or bypass.' It also names the exact information returned, giving the agent a clear model of the tool's safe, side-effect-free behavior. This is exceptional transparency for a zero-annotation 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 two tightly written sentences with no filler. It front-loads the most important fact ('Read-only preflight'), then packs scope, outputs, and exclusions into a compact sequence. Every sentence earns its place and the conciseness aids quick agent parsing.

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 output schema, the description lists the categories of returned data (revisions, policies, priorities, relation safety), which helps. However, all five parameters are optional, and the description does not explain which combinations are valid or what happens when only some IDs are supplied. The ambiguity around atom IDs versus memory IDs also leaves an incomplete picture for an agent deciding what to pass.

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 80%, so the schema already documents most parameters. The description adds minimal parameter-level meaning beyond the schema; it references a 'canonical/duplicate atom pair' but does not explain the relationship between the atom_id and memory_id parameters, which is a source of potential confusion. Baseline 3 is appropriate because the schema does the heavy lifting, but the description does not enrich parameter understanding.

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 'Read-only preflight for memoryguard_memory_merge_safe', making the verb, resource, and role immediately clear. It explicitly says what it resolves ('one explicit canonical/duplicate atom pair'), what it returns ('current atom revisions, policies, priorities, and relation safety'), and what it does not do ('does not write transactions...'). This clearly distinguishes it from the merge_safe sibling and from write-oriented memory tools.

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 clearly frames this as a preflight check for memoryguard_memory_merge_safe, so an agent can infer it should be used before executing a merge to inspect expected effects. It also states there is 'no force or bypass', setting expectations that this only reports safe preconditions. It does not explicitly name alternatives or say 'use memoryguard_memory_merge_safe when you intend to write', but the read-only/write contrast makes that implication strong 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?

There are no annotations, so the description carries the behavioral transparency burden. It explicitly says 'Read-only,' which reassures that no mutation occurs, and 'single' clarifies scope. It does not, however, describe behavior for missing IDs, access controls, or the meaning of 'shared' beyond the parameter schema.

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

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

The description is two tight sentences with no filler. The core operation and selector are front-loaded, and the read-only qualifier is a useful, unambiguous addition. Every word earns its place.

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

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

For a simple read-by-id tool with one required parameter and no output schema, the description is nearly complete. It covers what the tool does and the safety profile. It could mention return behavior or error cases, but the operation is straightforward enough that this is not a critical 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 description coverage is 100%, so the parameters are already well documented. The description only restates memory_id in the prose and adds no additional semantic value for agent_instance_id. Baseline 3 is appropriate because 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 specific action ('Read'), a specific resource ('single shared memory record'), and the key selector ('by memory_id'). This clearly differentiates it from sibling tools like memory_search or memory_write without requiring schema inspection.

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 when you have a memory_id and need that specific record. However, there is no explicit guidance on when to prefer memory_search or other read-related siblings, nor any exclusions or prerequisites. Minimal but not misleading.

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 and does add a useful behavioral signal: 'Read-only.' However, it does not clarify retrieval behavior such as default status filtering, semantics of the search modes, or whether quarantined/deleted records are included by default, leaving that to the schema.

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

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

The description is two short sentences with the action and object front-loaded, followed by a compact safety cue. Every word earns its place and there is 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 description provides the core operation and filter dimensions, and the schema documents all parameters and defaults. However, with no output schema and no sibling differentiation, an agent is left to infer the return shape and when to choose this tool over the many related search/read tools.

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

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

Schema description coverage is 100%, so all six parameters already carry meaningful descriptions and defaults. The tool description only names three filter axes (query, kind, status) and adds no parameter-level detail beyond the schema, so the baseline 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 states a specific action and resource: 'Search shared memory records', with clear filter dimensions 'by query, kind, or status'. It does not explicitly differentiate itself from sibling tools like memory_read or history_search, but the search framing is still clear.

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 tool's purpose implies it should be used when finding shared memory records by flexible filters, but there is no explicit guidance about when to prefer it over memory_read, history_search, or knowledge_search. No when-not-to-use conditions or alternative routing are 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?

There are no annotations, so the description carries the burden. It explicitly labels the operation as 'Read-only' and discloses the specific status aspects it returns. This gives the agent reasonable safety and behavior expectations for a status check.

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 focused sentence, front-loading the main action and result categories with zero 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?

The tool is low-complexity: no required parameters, no output schema, and a straightforward read-only status check. The description covers what the tool returns. Minor ambiguity remains about how the 'shared memory group' is identified given the only parameter is an optional identity check, but this is a small gap for such a simple tool.

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

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

The single optional parameter is fully described in the schema (identity consistency check, trusted MCP environment authoritative), so the description adds no param-level meaning. With 100% schema coverage, the baseline 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 specifies a clear verb ('Get') and resource ('shared memory group status'), and itemizes the output contents (record counts, event counts, conflicts, quarantine). It is distinguishable from many siblings like memory_read or memory_write, though it does not explicitly differentiate from other status-style tools (canonical_status, projection_status) in the sibling list.

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 about when to use this tool versus alternatives. The description implies it is for checking group status, but with many status-related siblings and no exclusions or alternative routing, an agent must infer usage 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?

Descriptions carry the full burden when no annotations are provided. This description does disclose a key side effect: 'Records a DecisionEvent,' and the verb 'Update' signals mutation. However, it does not mention reversibility, permission requirements, effects on related records or bindings, or what happens to unspecified fields, leaving notable behavioral gaps.

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 or repetition. The primary action is front-loaded, and the side-effect note is economically stated. Every phrase adds 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 tool's moderate complexity, the description is minimal but paired with a richly descriptive schema that covers parameter nuances such as the audience restriction for 'always' records and atom_id mapping. The missing pieces—explicit sibling routing and return-value behavior—are not critical given the schema's strength and the absence of an output schema. Overall, the description plus schema provides sufficient context for correct invocation.

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

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

The schema has 100% description coverage for all 10 parameters, so the description does not need to explain parameter meaning. Mentioning body, kind, and status only echoes field names without adding semantics beyond the schema. The baseline of 3 is appropriate because the schema is already doing 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 clearly states the operation ('Update') and the resource ('existing memory record'), with a parenthetical hinting at updatable fields (body, kind, status). The word 'existing' helps separate it from memoryguard_memory_write, but it does not explicitly name or contrast sibling tools. It is specific and unambiguous enough for an agent to grasp the core action.

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—modifying an existing memory record—is implied by the wording, but there is no explicit guidance on when to choose this tool over memoryguard_memory_write or memoryguard_memory_delete. No exclusions, prerequisites, or alternative-tool routing are provided. The agent must infer usage from the action verb and sibling names.

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

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

With no annotations, the description carries the full burden, and it does meaningful work: it discloses the auto-organize pipeline (classify, dedup, supersede, conflict, quarantine) and the return contract (memory_id and auto_actions). "Supersede" and "quarantine" honestly hint that existing memories can be affected, though it stops short of clarifying whether dedup/supersede can alter or destroy existing records.

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

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

Two sentences with zero filler. The core purpose is front-loaded first, followed by side-effect disclosure and the return contract. Every clause earns its place, and the auto-organize list is compact and scannable.

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 complex 9-parameter mutation tool with no output schema and no annotations, the description covers the core behavior, the auto-organize side effects, and a minimal return contract. Gaps remain: no mention of write_policy's propose_only non-destructive mode, no explicit warning that auto-organize can affect existing memories, and no routing guidance toward memory_update for existing-record edits.

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 9 parameters with meaningful per-field descriptions. The description itself mentions no parameters and adds no semantics beyond the schema. The baseline 3 applies because 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?

"Write a new memory record" uses a specific verb, a specific resource, and the "new" qualifier, clearly marking this as the creation operation. It is immediately distinguishable from siblings like memory_update, memory_delete, memory_read, and memory_search. The auto-organize pipeline detail further differentiates it from a plain append.

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 "new" qualifier implies this is for creating records rather than modifying existing ones (memory_update) or retrieving them (memory_read/memory_search). However, the description never names alternatives or states when-not-to-use conditions. Usage guidance is left to inference from the verb and resource rather than explicitly routed.

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 clearly states the tool is read-only, requires a governance scope, and describes the empty-response shape including possible reason values. This gives the agent meaningful behavioral expectations beyond the schema.

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

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

The description is two sentences with no redundant wording. It front-loads the core action and read-only nature, then gives the scope requirement and a compact return-shape summary. 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?

For a read-only tool with four parameters and no output schema, the description covers the scope requirement and the empty-case return value. However, it does not describe the shape of a successful non-empty response, nor does it clarify what 'neuron graph projection' contains or how the response should be interpreted. This is a notable gap given the absence of an output schema.

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 value by declaring that agent_instance_id or share_group_id is required, even though the schema lists no required parameters and marks them as mutually exclusive. This is a meaningful clarification that helps the agent construct a valid call.

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 ('Read') and a specific resource ('scoped neuron graph projection'), clearly identifying what the tool operates on. The 'read-only' qualifier reinforces its non-mutating nature. However, it does not explicitly differentiate it from sibling read tools such as memoryguard_projection_status or memoryguard_knowledge_read, so it falls just 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 an explicit usage prerequisite: the caller must pass either agent_instance_id or share_group_id. This is useful guidance for when the tool can be invoked. However, it does not explain when to choose this tool over related alternatives, nor does it mention exclusions or fallback options.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly says 'Read-only' and 'Always allowed, even when governance is degraded,' disclosing side-effect safety and availability under unusual conditions. It does not describe error behavior or output formatting, but for a simple status read this is solid coverage.

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

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

Two short sentences front-load the core purpose, list the exact status fields, and then add an availability caveat. Every word contributes to an agent's understanding, with 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?

The tool is simple: two optional parameters with defaults and no output schema. The description names the return concepts (projection_lag / projection_error / scopes), which is enough for an agent to know what it will receive. It could elaborate on how to interpret those fields, but nothing critical is missing for selecting and invoking the tool.

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

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

Schema description coverage is 100%, so the input schema already documents both parameters with their defaults. The description adds only indirect parameter meaning via 'for a group,' which maps to share_group_id. This matches the baseline of 3 when the schema does most of the work.

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 identifies the resource: 'Read-only projection status (projection_lag / projection_error / scopes) for a group.' It distinguishes this from sibling tools by emphasizing that it is always allowed, even under degraded governance. It lacks an explicit action verb like 'get' or 'return', so it stops just short of a top score.

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 clear operational guidance: 'Always allowed, even when governance is degraded' tells an agent this is the safe status check when other tools may be blocked. It does not explicitly name an alternative or say when not to use it, but the read-only and always-allowed context is strong enough to guide 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?

With no annotations provided, the description carries the full behavioral disclosure burden and succeeds: it states what is installed/repaired, per-provider differences, the personal-binding guarantee, the admin requirement, and idempotence. This goes well beyond a generic 'install provider' statement.

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 dense sentence with no filler. It front-loads the action and resource, then packs per-provider behavior, binding guarantees, privileges, and idempotence into the remaining clauses 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?

The tool is a complex install/repair operation with no output schema and no annotations, but the description covers the main prerequisites, side-effect scope, and behavioral guarantees an agent needs before invoking. It could mention what a successful call returns, but the description is still complete enough for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful provider-specific semantics: Claude/Codex/Cursor get the full hook path while TRAE falls back to MCP+rules, and it clarifies binding behavior tied to agent_instance_id. This enriches the parameter meaning beyond the schema.

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

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

The description opens with a specific verb-resource pair: 'Install/repair the provider's global MCP, redirect rules, and supported user-level lifecycle Hook.' It is clearly distinct from sibling tools like memory guard memory operations or binding queries, and it even differentiates supported providers and the TRAE fallback behavior.

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 provides clear context for when to call this tool: to install or repair provider-level MCP, redirect rules, and lifecycle hooks, while also requiring admin capability and noting idempotence. It does not explicitly name an alternative sibling to avoid, but the usage conditions are specific enough to guide 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?

With no annotations provided, the description carries the full burden, and it explicitly states 'Read-only.' This signals no side effects and aligns with the tool's resolver nature. It doesn't detail error behavior when an AgentBinding is missing, but for a simple read-only resolution this is acceptable.

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 purpose is front-loaded, and the usage placement is stated immediately, making the description easy to scan and act on.

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

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

For a low-complexity read-only resolver with fully schema-documented parameters, the description provides enough context: what it resolves, why it exists, and when to call it. The lack of an output schema is a minor gap, but the tool name and description make the return concept 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds that resolution is 'based on its AgentBinding,' which gives context for agent_instance_id, but it doesn't add significant meaning beyond the parameter 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 uses a specific verb ('Resolve') and a specific resource ('which share_group_id an agent should write to'), and it explicitly ties the resolution to the AgentBinding. This clearly distinguishes it from sibling tools like memory_write or binding_list, since its single job is to determine the group before writing.

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

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

The description gives clear placement guidance: 'Agents should call this before memory_write to know their group.' It does not explicitly discuss when not to use it or name alternatives, but the intended context is obvious and well-scoped.

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 disclosure burden. It explicitly reveals the fail-closed behavior, the trust boundary definition, and the admin-capability prerequisite — the key safety-critical traits of a rule-creation mutation. It does not mention idempotency semantics despite the presence of idempotency_key, nor what happens on success, but the most important behavioral traits are well covered.

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 dense sentences with zero filler. The core action is stated first, and the safety-critical scoping constraint is front-loaded immediately after. Every clause carries information an agent needs before invoking the tool.

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 7-parameter mutation tool with no annotations and no output schema, the description fully covers the make-or-break decision for an agent: what scope is allowed by default and what is required to widen it. The main gaps are the lack of return-value expectations and idempotency_key behavior, which are secondary for a rule-creation action but still relevant.

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 71%, placing the baseline near 3. The description adds genuine meaning to the scope and manual parameters: it explains that auto mode rejects broad targets and limits to the trusted agent/project cwd, and that manual=true requires admin capability. It adds less value for idempotency_key and workspace, which remain schema-only.

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: 'Create one mandatory rule from text.' It also clarifies the distinguishing trait of the 'auto' suffix by explaining that automatic scope inference is fail-closed, which separates this from any manual rule-creation path. This is unambiguous and 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 gives clear context on when the auto path is usable: only the trusted current agent or that agent plus the trusted project cwd. It also states the exact conditions for broader scope (manual=true, explicit scope object, admin capability). It stops short of naming sibling alternatives or stating explicit 'use X instead' exclusions, so it gets a 4 rather than a 5.

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

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

Annotations are entirely absent, so the description carries the full burden. It does disclose the most critical behavioral trait, 'Read-only', which tells an agent this operation will not mutate state. However, it does not cover what happens for an unknown decision_id, whether special permissions are required, or what the response contains, leaving the behavioral picture thin.

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

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

Two short sentences totaling nine words, with the verb, object, and key identifier front-loaded. The 'Read-only' qualifier is a single trailing phrase that earns its place. There is zero 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?

Adequate for a simple 2-parameter read operation, but gaps remain: the role of workspace is unexplained, there is no output schema so the return shape is undefined, and the domain concept 'explainable rule lifecycle decision' is never defined. An agent can infer basic invocation from 'by decision_id' but must guess about scoping and response expectations.

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 partly does by clarifying that decision_id is the lookup key ('by decision_id'), but it says nothing about the optional workspace parameter, which presumably scopes the read. Meaning is supplied for one of two parameters only.

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

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

The description states a specific verb ('Read'), a resource type ('one explainable rule lifecycle decision'), and the key identifier ('by decision_id'). The trailing 'Read-only' reinforces its non-mutating nature and implicitly separates it from mutation siblings like memoryguard_rule_undo and memoryguard_rule_feedback. It loses a point because 'explainable rule lifecycle decision' is undefined domain jargon and sibling differentiation is implied rather than 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?

No guidance on when to use this tool versus alternatives is provided. It does not reference related sibling tools such as memoryguard_explain or memoryguard_rule_scope_stats, nor does it give any conditions, exclusions, or context for when this read is the right choice.

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 a write operation, a one-to-one receipt binding, and a loop-closing purpose. It does not describe side effects, whether feedback can be replaced or duplicated, or any auth/audit implications, leaving some behavioral gaps.

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 with distinct information: the action, the purpose, and the binding constraint. Front-loaded with the primary verb and resource, with no filler or restatement 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?

The tool has 8 parameters and no output schema, but the schema fully documents parameters. The description provides essential operational context: when to call (after a bootstrap match) and the one-to-one receipt binding. It could mention the full outcome enum and confidence/idempotency semantics, but those are optional and schema-described, so the gap is minor.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by asserting the one-feedback-per-receipt_id constraint, which goes beyond the schema's note about receipt_id. It also previews outcome categories, even though the list is 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 identifies a specific action ('Record explicit evidence') and a specific resource ('mandatory-rule bootstrap match'), and clarifies that it closes the loop for outcome decisions. It distinguishes from sibling read/undo tools, though 'bootstrap match' relies on domain jargon and the listed outcome set omits exception/ignored.

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 places the tool after a bootstrap match has been evaluated, for recording the observed outcome. It does not explicitly name alternatives or exclusions, but the context is sufficient to direct an agent away from rule_decision_read or rule_undo.

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

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

With no annotations, the description carries the full burden. It usefully discloses the privileged auth context and the single-use capability gate, but does not explain side effects, whether the capability is consumed, or what state changes occur beyond 'acknowledge.'

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 unnecessary filler. It earns conciseness credit, though the dense use of jargon like 'AccessContext' makes it less approachable than it could be.

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 five parameters, a nested object, no annotations, and no output schema, this description is too sparse. It fails to explain the merge workflow, how the required fields are obtained, or what the caller should expect after invoking the tool.

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

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

Schema coverage is only 20%, and the description adds minimal parameter-level meaning. It hints that capability_token is the server-issued single-use capability, but it does not clarify proposal_id, idempotency_key, workspace, or the nested mutation_receipt beyond the schema's sparse 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 action—acknowledge first-merge risk—and identifies the mechanism: a server-issued single-use capability and trusted admin AccessContext. It is reasonably distinct from sibling merge tools like issue/approve, though it could be more explicit about how it differs.

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

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

The description implies when this should be used: after a server-issued capability has been obtained and when operating with trusted admin context. However, it does not explicitly mention alternatives or when not to use this tool, leaving workflow routing mostly 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 does disclose two important behavioral traits: the capability token is single-use and the operation requires a trusted admin AccessContext. However, it does not explain what approving the merge actually does to rules, whether the action is reversible, what happens to the proposal after approval, or the response/error 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 words. It is concise, but for a security-sensitive operation with five required parameters and nested objects, the extreme brevity borders on under-specification rather than genuine completeness.

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 — six parameters, nested mutation_receipt object, no output schema, no annotations, and a sensitive admin approval action — the description is incomplete. It omits the expected workflow, the meaning of expected_definition_revisions, the idempotency model, and the consequences of approval, leaving an agent under-equipped 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?

Schema description coverage is only 17%, so the description needed to compensate for undocumented parameters such as proposal_id, expected_definition_revisions, idempotency_key, and workspace. It only adds meaning for capability_token by describing it as server-issued and single-use; the other required parameters remain semantically opaque.

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 ('Approve') and a specific resource ('one candidate rule-merge proposal'), making the core action immediately clear. It also distinguishes this tool from siblings like memoryguard_rule_merge_capability_issue and memoryguard_rule_merge_acknowledge by focusing on approval rather than issuing, acknowledging, or cooldown-clearing.

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 should be used after a server-issued capability token has been obtained and with an admin AccessContext, which gives some guidance. However, it does not explicitly state when to use this tool versus sibling merge-related tools, nor does it give exclusion conditions or a workflow sequence.

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

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

With no annotations, the description carries the behavioral burden and does a good job: it discloses that the token is opaque and single-use, requires a trusted admin AccessContext, is returned only once, and that persistent storage keeps only a hash. This gives an agent meaningful security-relevant behavior beyond basic intent, though it doesn't address idempotency or failure 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?

Three sentences deliver the essential purpose, authorization requirement, and token-handling behavior with no redundant words. Information is front-loaded and every sentence adds distinct 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 security-sensitive capability issuance tool with six parameters, a nested object, no annotations, and no output schema, the description is incomplete. It does not explain how the returned raw token should be used, what the response shape is, how ttl_seconds and idempotency_key behave, or how this capability is consumed by later steps like rule_merge_approve.

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

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

Schema description coverage is only 33%, and the tool description does not compensate by explaining proposal_id, mutation_receipt, idempotency_key, recovery_secret, ttl_seconds, or workspace. The phrase 'candidate proposal' hints at proposal_id, and 'single-use' relates loosely to token semantics, but most parameters remain unexplained, leaving an agent to guess their roles.

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 object: 'Issue one opaque, single-use rule-merge capability for a candidate proposal.' This clearly names the action, resource, and scope, and the 'capability' framing distinguishes it from siblings like rule_merge_approve and rule_merge_acknowledge.

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: for a candidate proposal, when in a trusted admin context. However, it does not explicitly state when not to use it, nor does it mention the alternative merge-related tools or the expected sequence with rule_merge_approve/acknowledge. Usage context is present but exclusions and alternatives are absent.

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 behavioral disclosure burden. It reveals that this tool mutates state by clearing a cooldown and that the capability is single-use, but it does not describe side effects, idempotency behavior, error cases, or what happens when the capability is invalid or already consumed.

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 that states the action and key prerequisites without redundancy. It loses a point because "trusted admin AccessContext" is inserted as if it were an input or context parameter, which may confuse an agent given that no such parameter appears in the schema.

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

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

This is a mutation tool with five parameters, a nested object, no annotations, and no output schema, yet the description provides only a high-level statement. An agent would not know how to construct the required inputs, what success or failure looks like, or how this fits into the broader rule-merge workflow.

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

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

Schema description coverage is only 20%, so the description must compensate for undocumented parameters. It vaguely explains capability_token as a "server-issued single-use capability" and mentions an AccessContext that is not in the schema, but it does not clarify proposal_id, idempotency_key, workspace, or mutation_receipt semantics beyond the schema's own minimal receipt 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 names a specific action and resource: "Clear one rule-merge proposal cooldown." This distinguishes it from related rule-merge siblings like approve, acknowledge, and capability_issue, though it does not explicitly contrast them. The phrase "trusted admin AccessContext" is somewhat vague but does not obscure the core purpose.

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 requirement for a "server-issued single-use capability and trusted admin AccessContext" implies prerequisites and operating context. However, it never states when to prefer this tool over related rule-merge tools like rule_merge_approve or rule_merge_acknowledge, nor does it describe conditions 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.