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 identifies this as a mutation and explains retire semantics, but omits permissions, whether amendments are reversible, what happens to a wf_id that doesn't exist, and what the amend operation actually changes.

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

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

Two short sentences, front-loaded with the core action and followed by the one non-obvious flag behavior. 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?

An output schema exists so return values need no explanation, but for a 5-parameter mutation tool with zero annotation and zero schema coverage, the description leaves most of the calling contract undocumented.

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% across 5 parameters. The description only explains retire; wf_id, move, trigger, and reason get no semantic detail, so an agent must guess whether move is a new heuristic text or a sequencing field.

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 pair (amends/retires) and a specific resource (workflow heuristic in The Cabinet). This distinguishes it from cabinet_record_workflow and cabinet_list_workflows implicitly, though no sibling is named outright.

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

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

Gives a clear condition for the retire path ("when superseded or no longer firing"), but says nothing about when to amend versus create a new workflow, and does not name an alternative 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 behavioral burden. It discloses that results are 'active' heuristics and emphasizes low token output, which is useful. But it does not state permissions, pagination behavior, whether results are cached, or any other operational 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 short and front-loaded, with the core action in the first sentence and useful category/usage details following. The phrase 'high-density, low-token' is slightly promotional, but overall every sentence 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 simple two-parameter list tool with an output schema, the description covers the main purpose and category values. However, it leaves the 'search' parameter undocumented and does not clarify whether category values are exact or partial matches. It is adequate but incomplete.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It lists the possible categories, which adds meaning for the 'category' parameter, but says nothing about the 'search' parameter or how matching works. This is partial compensation 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: 'Returns ... list of active heuristics in The Cabinet.' It also scopes the output as high-density and low-token. It does not explicitly differentiate itself from siblings like cabinet_record_workflow or cabinet_refresh, so it stops short of a 5.

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

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

It provides a clear use case: 'Use this to pull operational tools without reading thousands of prompt tokens.' However, it gives no when-not-to-use guidance, no prerequisites, and does not name any alternative sibling tool. Usage is implied rather than fully specified.

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 does disclose key side effects: automatic next ID assignment, ledger persistence, and syncing workflow_notes.md. It still omits permission requirements, duplicate handling, and reversibility, which matter for a write 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?

Three compact sentences with the purpose front-loaded and useful category values included. No sentence is wasted, though the WF-M3 reference is opaque without external context.

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

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

The output schema means return values need not be explained, and the side effects are covered. However, with five parameters at zero schema coverage and no annotations, the description is not complete enough about parameter meaning or safety/prerequisite 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%, so the description needs to explain parameters, but it only lists the allowed category values. It does not clarify the intended content of title, trigger, move, or why, leaving most parameter semantics to inference.

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

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

States a specific verb and resource: records a new workflow heuristic. The word "new" implicitly separates it from cabinet_list_workflows and cabinet_amend_workflow, but those siblings are not named explicitly.

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

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

Gives a clear usage condition: use when a repeatable pattern has earned its place, citing Rule WF-M3. It does not state when not to use it or explicitly route edits to cabinet_amend_workflow.

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, and it does disclose the significant side effects: two files are written/updated, state is committed, and a restart is prepared. What is missing is whether the write overwrites prior last_session.md, whether repeated calls are safe, or what happens on failure.

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?

Four short sentences, front-loaded with the trigger condition and the main effects, with the optional workflow-recording path placed last. There is little waste, though the '(RP)' abbreviation adds a term the agent must infer without payoff.

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 9-parameter, zero-coverage, unannotated tool, the description explains the overall gesture but not how to populate the inputs. The output schema covers return values, but an agent still cannot tell what belongs in summary or next_move, which are required, making the definition under-specified for the tool's complexity.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate and largely does not. It loosely covers the optional proposed_workflow_* / stale_workflow_ids group as 'new or retired workflow heuristics,' but never mentions the two required parameters (summary, next_move) or entity_id and files_touched, and it gives no format or content expectations for any of them.

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 concrete operation (executing the Refresh Protocol) and enumerates the artifacts it produces: last_session.md, status_block.md, a state commit, and KV-cache readiness. That is far more specific than a restated name. It does not explicitly distinguish itself from the likely counterpart sibling cabinet_wake, so it stops short of a 5.

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

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

A clear trigger is given: use this when context hits roughly 70%, which tells an agent exactly when this tool becomes relevant. It also signals the optional workflow-heuristic path. It does not state when NOT to use it or name cabinet_wake / cabinet_record_workflow as the alternative for related operations.

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 discloses useful traits: codeword validation, ingestion of status_block.md and last_session.md, a <250 token budget, DUMEdb state checking, and a tight briefing return. It does not explain failure behavior, invalid-codeword handling, or whether it mutates any state.

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 front-loaded with the critical mandatory instruction and then lists the operational sequence. It is slightly repetitive with emphasized 'MANDATORY' and 'DO NOT' phrasing, but each sentence supports correct invocation.

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

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

For a mandatory session-bootstrap tool with an output schema, the description provides enough context: when to call it, what it ingests, what it checks, and what it returns. Remaining gaps are around error handling and side effects, which are not fully covered without annotations.

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

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

There is one optional codeword parameter with a schema default, but schema description coverage is 0%. The description says the codeword is validated and references 'box is the game' as a trigger phrase, but it does not define valid values, format, requiredness, or the effect of an invalid codeword.

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 initialization operation: executes the Wake Handshake, validates a codeword, ingests compass files, checks DUMEdb state, and returns a briefing package. It clearly distinguishes this bootstrap action from sibling tools by forbidding filesystem searches and other actions until it runs.

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 explicit timing and trigger conditions: every new session, greetings, status requests, 'catch me up', 'wake', 'start', 'briefing', and the phrase 'box is the game'. It also states a clear exclusion: do not search the filesystem or take other actions until this tool has executed.

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. It usefully discloses atomicity, schema auto-registration for novel opcodes, and 32-byte record packing, but omits mutation risk, overwrite semantics, required permissions, and 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?

Two sentences with no wasted words, and the core action and storage target are front-loaded. The second sentence adds useful implementation context without rambling.

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 mutation operation with no annotations, zero schema description coverage, and an output schema that handles return values. The description leaves out entity_id semantics, mutation risks, and usage context, making it insufficient for fully confident 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%, so the description must compensate for all three parameters. It partially explains opcode_name (resolved from SchemaDictionary or auto-registered) and value (packed into a hardware-aligned 32-byte record), but entity_id is entirely undocumented and value formats are not clarified.

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 ('commits') and resource ('discrete state register mutation') and identifies the storage backend ('DUMEdb LMDB storage'). It clearly contrasts with read-oriented siblings like dume_read_state, though it does not explicitly name an alternative.

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

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

The description explains what the tool does mechanically but gives no guidance on when to use it versus alternatives such as dume_read_state or dume_query. There are no conditions, prerequisites, or exclusions stated.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the scratchpad is reset and persistent registers remain intact, but it does not state whether the reset is destructive/recoverable, idempotent, permission-gated, or what happens for an unknown entity_id.

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

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

The description is a single front-loaded sentence with no filler. It states the primary action first and adds the important preservation constraint second.

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 and has an output schema, so return values need not be described. Still, as an unannotated mutation-like operation, the description should do more to clarify entity_id semantics and the safety/reversibility profile of resetting the scratchpad.

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 single entity_id parameter. Instead it only says "specified entity_id" and does not explain what an entity_id identifies, the significance of the default value, or behavior when the parameter is omitted.

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

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

The description gives a specific verb ("Resets") and resource ("conversational scratchpad buffer") scoped to an entity_id. It distinguishes the scratchpad from persistent DUMEdb LMDB registers, though it does not explicitly compare itself to sibling tools like dume_commit_state or dume_read_state.

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

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

The phrase "while keeping persistent DUMEdb LMDB registers intact" implies when to use it: clearing ephemeral conversational state without touching durable registers. However, it gives no explicit when-to-use/when-not-to-use guidance or named alternatives among the many sibling dume 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 the full behavioral burden; it does disclose that returned data is sanitized and that it only applies to active error cards, which implies expired/unknown fingerprints will not resolve. It does not say what error or response occurs when the fingerprint is unknown or inactive, nor confirm read-only behavior beyond the word 'Returns'.

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

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

One compact sentence with the core resource and its scope front-loaded, and no filler. It is slightly under-packed rather than bloated, so conciseness is not the problem.

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

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

An output schema exists, so return values need not be described, and the path plus sanitization note is useful context. For a single-parameter retrieval tool with no annotations, however, it omits the failure mode for unknown/expired fingerprints and how to source a fingerprint.

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

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

Schema coverage is 0% and the single required 'fingerprint' parameter is an untyped string. The description narrows it to an 'active error fingerprint card', which adds some meaning, but gives no format, casing, or guidance on where to obtain a fingerprint (e.g., from dume_query or dume_get_incident_rca).

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

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

States a specific verb and resource: returns a sanitized stack trace plus diagnostic context for an active error fingerprint card. That is well beyond tautology. It stops short of differentiating from the nearest sibling, dume_get_incident_rca, which an agent could plausibly confuse it 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?

The phrase 'active error fingerprint card' implies the usage precondition (the error must be active), so scope is partially conveyed. But there is no explicit when-to-use/when-not guidance and no reference to dume_get_incident_rca or how fingerprints are obtained, leaving the agent to infer routing.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a read operation and where data comes from (~/.dume/assets/incidents/), but says nothing about behavior when the incident is not found, permission requirements, or whether the runbook is static or generated.

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

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

One sentence, front-loaded with the return value and scoped by the resource. Every phrase adds information with 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?

An output schema exists, so return values need not be explained. However, for a single required parameter with 0% schema coverage, the description should specify incident_id format or source. It also omits error behavior, which matters for a lookup tool with no annotations.

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

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

Schema description coverage is 0% and the sole parameter, incident_id, is undocumented beyond its type. The description does not explain the expected format or where incident IDs come from (e.g., dume_list_module_context or logs), leaving a critical gap for invocation.

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 ('Returns') and resource ('root cause analysis and resolution runbook for a logged incident card'), including the storage location. Clear enough to distinguish from generic reads like dume_read_adr or dume_get_error_details, though it doesn't 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?

No guidance on when to use this versus alternatives such as dume_get_error_details or dume_list_module_context. The agent must infer the selection criteria from the name and description 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 and does disclose meaningful side effects: secrets/PII scrubbing, a Markdown card written to ~/.dume/assets/, and active state pointer commits to DUMEdb. It does not cover failure/idempotency behavior or permission needs, so it is strong but not complete.

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

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

Two tight sentences, front-loaded with the action and scope, followed by processing/side-effect details. 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 side-effect story is adequate and an output schema exists, so return values need not be explained. However, for a 3-parameter tool with 0% schema coverage and no annotations, the silent treatment of entity_id and payload formatting is a real gap 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%, so the description must explain parameters, but it mentions none of the three explicitly. The listed payload types loosely map to intake_type values, yet the payload format and entity_id (default 'MadBrad-Nostra-01') are left entirely unexplained in both schema and description.

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

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

The description states a specific verb and resource ('Ingests an enterprise JSON payload') and enumerates the three payload kinds (PR design proposal, APM stack trace, incident postmortem ticket), which clearly separates it from the read/query/commit-state siblings. It stops short of naming an alternative tool, so it is clear but not fully sibling-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 enumerated payload types imply when the tool applies, but there is no explicit 'use this when…' or 'use X instead when…' guidance, and no mention of prerequisites (e.g., whether a schema must exist first, or how this relates to dume_commit_state). Usage is implied rather than stated.

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 it does clarify the returned content set. However, it omits that this is a safe read, what happens when 'module' is left at its empty default, and whether results are paginated or capped.

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 front-loaded sentences with no filler. The enumeration of returned artifacts is the right thing to lead with, and nothing extraneous is included.

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

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

An output schema exists, so return structure needn't be explained. Still, for a tool with an undocumented parameter default and no annotations, the description leaves a meaningful gap around scoping behavior when 'module' is omitted.

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

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

Schema coverage is 0%, so the description must compensate. It expands 'module' to 'specified module or system area', which adds slight meaning, but never explains the empty-string default or whether omitting the parameter returns context for all modules.

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?

Names a specific verb ('Returns') and enumerates the resource set: ADRs, error fingerprints, and incidents. It distinguishes itself from siblings like dume_read_adr and dume_get_error_details by being the aggregate listing tool, though the description doesn't state that contrast explicitly.

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

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

The word 'list' and the aggregate scope imply when to use it rather than the per-artifact readers (dume_read_adr, dume_get_error_details, dume_get_incident_rca), but no explicit when-to-use or exclusion is stated. An agent must infer the routing decision.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. 'Returns' strongly implies a read-only listing operation, and the description clarifies the content scope (active specs, including pre-registered and [AUTO] opcodes), but it does not explicitly cover permissions, side effects, or rate-limit 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 redundant or filler content. It states the return scope 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?

With zero parameters and an output schema present, the description need not explain return values or parameter syntax. It sufficiently describes the schema-listing operation, though it omits usage context that could help an agent choose this tool over sibling listing/query 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 the baseline score is 4. The description does not need to explain parameter semantics, and the empty schema is consistent with a no-argument listing operation.

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 ('Returns') and resource ('active DUMEdb schema dictionary specifications'), making the tool's purpose clear. It also narrows scope by noting pre-registered and auto-discovered [AUTO] opcodes, though it does not explicitly differentiate itself from siblings such as dume_list_module_context.

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 is returned but gives no explicit guidance on when to use this tool versus alternatives like dume_list_module_context or dume_query. There are also no stated prerequisites or 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, and it does add real behavioral context: it clarifies the tool reads LMDB-backed state, is non-destructive to raw documents, and avoids token-heavy retrieval. It omits result ordering, the meaning of the limit default, and any explicit read-only declaration, so the safety profile must be inferred.

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 front-loaded in the first sentence, which is good. But phrases like 'hardware-aligned' and 'burning token context' are marketing flavor that consume space without adding invocation guidance, and the three-sentence block could be tightened.

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 presence of an output schema means return values need not be explained, and the read-only nature is reasonably implied. Still, with three parameters at 0% schema coverage and no annotations, an agent lacks enough to use 'entity_id' correctly or predict how 'limit' affects results.

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 meaningfully explains what the required 'query' parameter matches (opcodes, enum values, register names, text payloads), but 'limit' and 'entity_id' are entirely undocumented in both schema and description, leaving two of three parameters 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?

States a specific verb ('associative search') and resource ('active state registers and extension payloads in DUMEdb'), and lists the matchable content types. However, it never distinguishes itself from sibling lookups like dume_read_state or dume_read_adr, so an agent must infer which retrieval path to pick.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no sibling tools are named as alternatives. The line about not touching raw filesystem documents implies this is the cheaper lookup path, but the agent is left to infer that comparison against dume_read_state and dume_list_schemas.

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

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

With no annotations, the description does carry some burden, and it does establish that this is a file-content read from a specific directory (implying read-only, no mutation). However it says nothing about behavior when the ADR id does not exist (error vs empty result), whether content is truncated, or how the path is resolved.

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

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

Two short lines, front-loaded with the verb and resource, with no filler. The only weakness is the imprecise word 'target', which costs a word without adding 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?

An output schema exists, so return-value description is not required, and the file location is a nice touch. But for a tool whose only input is an undocumented identifier with no discovery path among the listed siblings, the definition leaves a real gap in how to call 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 0% and the single parameter adr_id has no description anywhere. The prose mentions 'target ADR' but never says whether adr_id is a filename, a slug, a numeric index, or a path, nor does any sibling tool appear to enumerate valid ADR ids.

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 ('Returns the content') and resource (an ADR markdown file) and even pins the storage location (~/.dume/assets/adrs/), which distinguishes it from siblings like dume_read_state and dume_list_schemas. It stops short of a 5 because 'target' is vague about which ADR is meant and nothing explicitly contrasts it with the other dume_* read 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 when-to-use or when-not-to-use guidance, no mention of prerequisites, and no hint about where the adr_id comes from. The only implied usage is 'you already have an ADR identifier', which the agent must infer.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that this is a direct zero-copy LMDB read and that records are decoded via SchemaDictionary, which usefully implies a read-only, non-mutating operation, but it does not explicitly state side effects, permissions, failure behavior, or consistency guarantees.

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 front-loaded sentences with no wasted words. The key action and technical mechanism are stated immediately.

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 output schema exists, so return-format explanation is not required, and the description provides useful technical context. However, it leaves gaps around usage guidance versus siblings, entity_id semantics, and read-only safety behavior, which matter for a tool with no annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It only says the read is 'for a given entity_id' without explaining the identifier format, expected values, or the schema-declared default.

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 (read) and resource (active state registers) and adds technical context about the LMDB zero-copy path and SchemaDictionary decoding. It is clear on its own but does not explicitly differentiate itself from siblings like dume_query or dume_read_adr.

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 when-to-use or when-not-to-use guidance and does not name alternatives. An agent must infer usage from the purpose statement alone.

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