Wyrm

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 discloses account-wide listing, default limit behavior, and that each quest's id is returned. It does not mention potential cost, ordering, or any side effects, though 'List' implies a read 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 compact, front-loaded with the core purpose, and every clause adds useful context: scope, filter option, account-wide framing, returned identifier, and default limit. No filler or redundancy.

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

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

Given no output schema, the description gives a minimal return shape ('Shows each quest's id') and explains the default limit and filter option. It is sufficient for an agent to select and call the tool correctly, though response details beyond id are left unspecified.

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 input schema already documents `limit` and `status`. The description adds only marginal restatement ('optionally filtered by status', 'at most 50 unless a limit is given') without deepening parameter meaning.

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

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

The description states a specific action ('List'), resource ('quests'), and scope ('across ALL workspaces for this account'), explicitly contrasting with 'the connection's default'. This clearly distinguishes it from the sibling `wyrm_quest_list` or other workspace-scoped 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 conveys when to use it: for account-wide quest visibility, not just the connection's default workspace. It does not explicitly name the default-scoped alternative, but the 'not just' phrasing provides clear contextual 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?

With no annotations, the description carries the full behavioral burden. It conveys that this is a persistent write operation ('durable', 'save') and that it is proactive and batched, but it does not disclose overwrite/merge behavior, idempotency, permissions, or side effects on existing storage. Core intent is clear, but consequential details are unspecified.

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. It front-loads the core action and scope ('Proactively batch-save durable knowledge... in ONE call'), then adds a terse usage heuristic. Every clause contributes 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?

For a write tool with all-optional parameters and no output schema, the description tells an agent what to capture, when to capture it, and that everything should be batched in one call. The workspace parameter is adequately handled by the schema, and the lack of return-value details is acceptable for a persistence 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 parameters are already documented. The description adds semantic grouping by mapping 'ground truths' to truths, 'lessons/decisions' to lessons, and 'quests' to quests, and 'capture signal, not chatter' helps agents judge what values are appropriate, which is value beyond the raw 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 clearly states a specific action—batch-saving durable knowledge—and lists the resources covered: ground truths, lessons/decisions, and quests. The 'in ONE call' phrasing differentiates it from single-purpose sibling tools like wyrm_truth_set or wyrm_quest_add, though it doesn't name an alternative 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?

It gives explicit usage context: prefer this tool as decision-grade facts emerge, and don't wait to be asked. 'Capture signal, not chatter' implies when not to use it (for trivial conversation), but no specific sibling alternatives or strict exclusion conditions are named.

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 behavioral disclosure. It does convey that the tool aggregates and presents existing memory data rather than performing a single lookup, and it names the types of content returned. However, it does not state whether the operation is read-only, how matching/relevance is determined, or what happens when nothing matches.

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

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

The description is a single, compact sentence that front-loads the core action and then lists the output components. Every phrase earns its place, with no redundancy or 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?

Given no annotations, no output schema, and a 50% parameter coverage gap, the description is too thin. It gives a useful overview of what the tool returns, but it lacks guidance on how the agent should choose it among many similar siblings, what constitutes 'relevant' or 'matching', and what to expect for edge cases like an empty memory or missing workspace.

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 50%, and the description adds little meaning to the parameters. 'task' is not explained beyond the tool's general purpose, and no additional semantics are given for 'workspace' beyond what the schema already states. The description should compensate for the undocumented parameter but does not.

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 action ('Assemble a task brief') and the resource scope ('this account's memory'), and it lists the expected contents: relevant ground truths, matching artifacts, and open quests. However, it does not explicitly differentiate this from sibling tools like wyrm_search or wyrm_recall, so it stops short of full clarity.

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 'Assemble a task brief' implies the intended use case: building a consolidated context summary for a task. But there is no explicit guidance about when to prefer this tool over alternatives, nor any stated exclusions or conditions.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds useful context by stating that decisions persist and remain traceable when truths change, but it does not disclose side effects, whether truth refs are validated, whether records are immutable, or what happens if a referenced truth no longer exists.

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 and a clear causal justification for why the tool exists. It is concise, though slightly terse given the number of parameters and the absence of richer behavioral detail.

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

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

Given no annotations, no output schema, and 50% parameter coverage, the description is too thin for an agent to fully understand how to invoke the tool correctly. It lacks operational context about the structure of a decision, the role of rationale, and how this recording action interacts with the decision-trace and truth-management siblings.

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 50%, and the description does not compensate for the undocumented parameters. It conveys that 'because' holds ground-truth references, but it never explains what 'decision' itself should contain or how 'rationale' relates to 'because' and 'decision'. This leaves two of four parameters underspecified.

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

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

The description clearly states the action ('Record'), the resource ('a decision'), and the related content ('ground truths it rests on'), making its core purpose obvious. It is distinguishable from trace/invalidate siblings by emphasizing creation and persistence, though it does not explicitly name those siblings or contrast with capture/remember 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 phrase 'so the rationale survives and can be traced when a truth later changes' implies the tool should be used when recording a decision at the time it is made. However, there is no explicit guidance about when not to use it or how it relates to alternatives like wyrm_decision_trace, wyrm_decision_invalidate, or wyrm_capture.

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 correctly indicates a read-only 'Show' operation and describes the navigational intent, but it does not disclose output shape, ordering, depth, or what happens for invalid/missing truth refs. Enough for a basic read tool, but not richly 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 concise sentences: the first states what the tool does and why, the second gives the exact input format. No filler, no redundant restatement of the tool name, and key 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?

This is a simple read operation with one required parameter and one optional workspace. The description explains the core outcome, the meaning of downstream cascade, and the input format. It does not describe the return structure, but for a listing/query tool this is a minor gap rather than a critical omission.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description reinforces the 'category.key' format for the truth argument, matching the schema. It adds minimal additional meaning beyond reuse of the schema's parameter 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?

Description states a specific verb ('Show'), a specific resource ('decisions that depend on a given ground truth'), and a distinctive behavior ('downstream cascade'). It clearly differentiates from the sibling 'wyrm_decision_upstream' by emphasizing the downstream direction and the use case of revisiting decisions if a truth changed.

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

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

Gives clear when-to-use context: when you need decisions affected by a ground truth change, i.e. the downstream cascade. It does not explicitly name alternatives or exclusions, but 'downstream cascade' and the purpose statement effectively signal the correct scenario versus upstream tracing.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly explains that the operation is non-destructive to history ('stays in history') and that the invalidated state is visible in traces. It does not mention permissions, reversibility, or downstream effects, but the core side effect is disclosed.

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

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

Two sentences deliver the action, rationale, side effect, matching behavior, and optional parameter semantics with no filler. The most important facts are front-loaded.

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

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

For a simple tool with three parameters and no output schema, the description covers the essential invocation details: what it does, when to use it, how matching works, and that the history is preserved. It could add explicit guidance on when not to use it or what response to expect, but nothing critical for correct invocation 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 67%, but the description adds important meaning beyond the schema: 'Matches by decision title prefix' clarifies how the decision parameter is used, and 'optionally record what supersedes it' supplements the superseded_by field. This compensates for the undocumented decision 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 states a specific action ('Mark a decision invalidated/superseded') on a clear resource, and adds distinguishing behavior: the decision 'stays in history but is flagged in traces.' This clearly separates it from other decision-related sibling tools such as wyrm_decision_trace or wyrm_decision_downstream.

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

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

The description gives an explicit trigger example ('e.g. a ground truth it rested on changed'), which helps an agent know when invalidation is appropriate. It does not name alternatives or exclusions, but the stated context is reasonably clear for this tool's narrow purpose.

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

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

The description discloses the two modes and their expected outcomes, which is useful. However, with no annotations provided, it does not explicitly state that the tool is read-only or has no side effects, leaving some of that burden unmet.

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 concise sentences with no filler. The core action is front-loaded, and the dual-mode behavior is packed into a single well-structured sentence.

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 two invocation modes and gives a broad sense of the return information, which is enough to call the tool for many cases. However, it lacks output format details, a definition of 'recent', and any clarification of how this tool relates to the decision-specific 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 schema already documents both parameters fully, and the description adds meaningful context by explaining what passing 'truth' accomplishes ('what to revisit when it changes') and what happens when it is omitted. The workspace parameter is not expanded, but the schema covers it adequately.

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 a specific action ('trace decisions') and defines two concrete modes: finding dependents of a truth and listing recent decisions with their foundations. However, it does not explicitly distinguish itself from sibling tools like wyrm_decision_upstream or wyrm_decision_downstream, so it falls short of a perfect 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 gives clear, direct usage context: pass 'truth' to find dependents, pass nothing to list recent decisions. It does not mention when to prefer a sibling tool instead, but the invocation branches are explicit and unambiguous.

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 transparency burden. It discloses a key behavioral trait: values are CURRENT, not historical, and matching is by decision title prefix. However, it does not state whether the operation is strictly read-only, what happens on no match or ambiguous prefix, or precisely how results are structured.

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 tight sentence that front-loads the core action, then adds the current-value purpose and the matching behavior. No words are wasted and every clause contributes useful 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?

For a straightforward two-parameter query tool, the description covers what it returns (ground truths with current values), why it is useful, and how arguments are matched. It lacks an explicit note about empty results or prefix ambiguity, but those are minor given the tool's simplicity and high schema coverage.

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 both parameters. The description adds little beyond the schema's own 'unique prefix' wording, though it reinforces the prefix-matching behavior. 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 uses a specific verb and resource: 'Show the ground truths a decision rests on (its upstream dependencies)' with current values. It clearly distinguishes itself from the sibling wyrm_decision_downstream by focusing on 'upstream.' The prefix-matching instruction adds operational clarity.

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 'so you can tell whether the basis still holds' provides clear context for when to use the tool: when checking whether a decision's founding assumptions remain valid. It does not explicitly name alternatives or exclusions, but the upstream/downstream contrast with sibling tools makes the intended use reasonably clear.

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

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

No annotations are provided, so the description carries the full burden. It clearly signals a read-only, non-mutating operation through 'check' and 'surfaces past dead-ends,' and adds account scoping. It does not describe return format or matching semantics, but for a simple check tool the behavioral profile is adequately disclosed.

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

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

Two short sentences with no wasted words. The instruction to use the tool before a fix is front-loaded, and the second sentence supplies the benefit without fluff 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 lightweight check tool with only two parameters and no output schema, the description provides enough context to select and invoke it correctly: when to call, what to query, and why it matters. A hint about the return value would round it out, but the absence is minor given the tool's simplicity.

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 reinforces the meaning of 'query' by calling it 'the approach/fix/target,' but it adds no new details about the workspace parameter or value formats 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 states a specific action—'check whether it has already failed'—against a specific resource ('past failures for this account'). It distinguishes itself from siblings like wyrm_failure_record or wyrm_failure_list by framing the tool as a pre-action validation check rather than a list or mutation.

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 tells the agent when to use it: 'BEFORE trying a fix or approach.' It also provides a clear rationale (avoid burning tokens re-deriving known-wrong answers), though it does not explicitly name alternative tools or 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does convey that the tool returns only unresolved failures and frames them as the current 'do not repeat' set, but it does not mention read-only behavior, ordering, pagination, or response shape. This is adequate but not rich for a no-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 a single, front-loaded sentence with no filler. Every part adds meaning: the verb, the filtered status, the account scope, and the 'do not repeat' semantic.

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 one optional parameter and a fully documented schema, the description covers the essential semantics well. The only gap is that with no output schema, return-value structure is not described, but the name and phrasing make the purpose sufficiently clear.

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

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

Schema description coverage is 100%, and the single optional parameter is already well documented in the input schema. The description adds 'for this account' context, but it does not significantly extend what the schema already explains, so the baseline of 3 applies.

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

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

The description uses a specific verb ('List') and resource ('failures'), and clarifies scope as 'active (unresolved)' and 'current do not repeat set.' This distinguishes it clearly from sibling tools like wyrm_failure_record, wyrm_failure_resolve, and wyrm_failure_check.

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

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

The description makes the tool's purpose clear, so when an agent needs to see active failures the usage is implied. However, it does not explicitly state when to prefer this tool over wyrm_failure_check, nor does it mention any alternatives 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 behavioral burden, and it discloses the key side effect: the recorded failure 'is blocked next time,' framing the tool as a 'counter-pattern firewall.' It does not discuss duplicate/overwrite semantics or reversibility, but the principal persistent effect is explicit.

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 action and effect, the second tells the agent what to capture. The parenthetical metaphor is compact and does not detract.

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 four-parameter, no-output-schema tool, the description is largely complete: it covers purpose, key side effect, and the required input fields. It could mention the optional workspace default or how a blocked failure surfaces, but the schema already documents workspace and the core behavior is stated.

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's 'Capture the scope, what it was tried on, and what went wrong' maps directly to scope/target/description but adds no new information beyond the property descriptions already present.

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: 'Record an approach that FAILED' and explains the intended consequence, 'so it is blocked next time.' It is clearly distinguishable from failure_check/resolve/list by its record action, though it does not explicitly name a sibling for contrast.

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

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

It gives clear context for use: after an approach has failed and should not be repeated. It implies the exclusion of non-failed approaches and does not mislead, but it does not explicitly name alternatives like wyrm_failure_check or wyrm_failure_resolve.

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 disclosure burden. It transparently describes the state-changing behavior: marking an existing failure resolved/superseded and lifting its blocking effect. It does not cover reversibility or return value, but for a single-id state transition, the core behavior is well disclosed.

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

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

One compact sentence with the action front-loaded and the qualifying condition in a parenthetical. Every element earns its place, with no redundant or filler 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?

For a simple tool with one required parameter and no output schema, the description fully explains when to call it, why, and what effect it has. The provenance of the id is already provided in the schema, so nothing essential 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?

The schema already fully describes the only parameter, 'id', as 'the failure id from wyrm_failure_list', so schema coverage is 100%. The description adds no additional parameter-level meaning, which is acceptable at the baseline of 3.

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

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

The description uses a specific verb ('Mark') on a specific resource ('a recorded failure') with a precise effect: resolving or superseding it so it no longer blocks. This clearly distinguishes it from siblings like wyrm_failure_record, wyrm_failure_check, and wyrm_failure_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?

The description states the exact condition for use: the underlying issue is fixed or the approach now works, so the failure should stop blocking. It does not explicitly name alternative tools or describe when not to use it, but the context is clear enough for an agent to select it 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 disclosure burden. It communicates that this is a write operation ('Add') and defines what a quest is, but it doesn't state what state the quest starts in, whether duplicates are allowed, whether 'open' is the default state, what side effects occur, or what the response looks like. For a mutation tool with zero annotation coverage, this is a meaningful gap.

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

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

A single 9-word sentence with zero filler. The core action is front-loaded, the domain term is clarified inline, and nothing extraneous is included. This is an appropriate size for a simple creation 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?

Given 4 parameters, no output schema, no annotations, and a large sibling family, the description is too thin for an agent to invoke the tool with full confidence. It doesn't disambiguate from wyrm_capture, doesn't explain the 'open' state semantics, and doesn't indicate what a successful call returns. The schema covers the workspace parameter, but the overall picture is 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 only 25% (only 'workspace' has a description), so the description should compensate for the undocumented title, detail, and priority parameters. It does not — the description adds no parameter-level meaning beyond what the field names imply. Some weight is carried by the self-explanatory names and the priority enum, but the description itself contributes nothing here.

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 ('Add'), a specific resource ('quest'), and clarifies the domain term with a parenthetical ('a tracked goal or task'). The qualifier 'open' adds state context, which helps distinguish it from wyrm_quest_complete and wyrm_quest_update. It doesn't explicitly name any sibling, but the core purpose is unambiguous.

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

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

No guidance is given about when to use this tool versus alternatives. Among the 30 siblings, wyrm_capture and wyrm_quest_claim/update could plausibly overlap with adding a quest, and the description gives the agent no decision criteria for selecting this one. Usage context must be inferred entirely from the name and schema.

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 key behavior: exact-id/title-prefix matching, refusal of already-claimed quests, and the force escape hatch. However, it does not explain what the tool returns, what happens on no match or ambiguous match, or what state changes occur beyond claiming.

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 and no filler. The description front-loads the core purpose, then covers matching and conflict behavior efficiently. Every clause contributes to correct tool selection and 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?

The description covers the primary claim, matching, and conflict logic, but no output schema means return values are unspecified, and edge cases like 'both quest_id and title provided', ambiguous prefixes, or missing matches are not addressed. For a tool with no annotations, this is a notable completeness gap.

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

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

The description adds meaning to the schema beyond raw field names: it explains that title is matched by prefix, that quest_id is exact, and that force bypasses the already-claimed refusal. Since schema coverage is 60%, the description meaningfully compensates for the uncovered/mostly-uncovered parameters such as title and force.

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

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

The description clearly states the action ('Claim an open quest'), the resource involved, and the purpose ('so others know it's being worked'). It also calls out the matching mechanism and the ownership conflict, distinguishing it from siblings like wyrm_quest_add, wyrm_quest_complete, and wyrm_quest_release.

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 makes the primary usage context explicit: claim open quests during multi-agent coordination so other agents can avoid duplicating work. It does not enumerate sibling alternatives like wyrm_quest_release or wyrm_quest_complete, but the context is clear enough for the agent to decide when this tool is appropriate.

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

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

No annotations are provided, so the description carries the full burden. It states a mutation ('mark completed') but does not disclose prerequisites (e.g., quest must exist), side effects, idempotency, or error behavior. For a write operation this is insufficient.

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, efficient sentence that front-loads the action and identification methods. There is no wasted text or redundancy.

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

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

For a mutation tool with no output schema and no annotations, the description omits return values, prerequisites, and consequences of completion. An agent lacks critical information to call the tool correctly and anticipate outcomes.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds the prefix-matching detail for title, which is also present in the schema. It provides minimal added value 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 clearly states the verb 'mark', the resource 'quest', and the action 'completed'. It also specifies two identification methods (exact id or title prefix), which distinguishes it from siblings like wyrm_quest_add and wyrm_quest_list. The purpose is unambiguous.

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

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

The description implies when to use the tool (to complete a quest) but does not explicitly contrast it with alternatives like wyrm_quest_update or wyrm_quest_claim. It lacks guidance on when not to use it or which sibling to prefer for other status changes.

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 available, the description carries the full burden and does add useful behavior: it reveals that each quest's id is shown and that results are capped at 50 unless a limit is provided. It does not disclose sorting, pagination beyond the cap, or whether the response contains only ids or additional fields.

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, no filler, and the key action and filter options appear first. Every clause earns its place: action, filters, output shape, and limit.

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 tool with no required parameters, the description and schema together are nearly sufficient: the caller knows what to pass, what to expect (ids, up to 50), and the default workspace behavior. The absence of an output schema and lack of distinction from wyrm_all_quests are minor gaps given the low 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 coverage is 67%, with limit and workspace already described and status defined by a self-explanatory enum. The description's phrase 'optionally filtered by status and/or workspace' adds minimal meaning beyond the schema, but is not misleading. It neither compensates for the undocumented status parameter nor enriches 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 states a clear action and resource: 'List quests, optionally filtered by status and/or workspace.' It also specifies the output shape ('Shows each quest's id') and the limit constraint. However, it does not differentiate itself from the sibling wyrm_all_quests, which appears to serve a similar listing 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 description implies usage through the optional filters ('filtered by status and/or workspace'), indicating common scenarios. It does not explicitly state when to prefer this tool over wyrm_all_quests or other siblings, nor does it mention any exclusions or prerequisites.

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. It discloses the matching behavior (exact id vs title prefix) and the result (quest becomes open), which gives the agent an accurate model of the effect. However, it does not mention whether other quests are affected, permission needs, or side effects (e.g., state changes). Given the complexity (a mutation of quest state), a 4 is appropriate as the core behavior is transparent, though minor gaps 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 of 19 words, front-loading the action and result, then specifying the matching criteria. Every word earns its place; there is no redundancy or filler. It is efficiently structured for quick 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?

Given the low complexity (3 scalar parameters, no output schema), the description covers the essential behavior: what it does, how to match, and the intended outcome. It does not document error cases (e.g., quest not found) or edge cases (e.g., multiple title prefix matches), but for a mutating tool with no annotations, it provides sufficient context for an agent to call it correctly in typical scenarios. A 4 is justified as the minor gaps are not critical for basic invocation.

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

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

Schema coverage is 67%, and the description adds key semantic guidance: it states that 'title' is matched by prefix (not exact), while 'quest_id' is matched exactlyikuha. This directly clarifies the primary parameter ('title') which lacks schema description. For a tool with only 3 simple parameters and 67% schema coverage, the description compensates well by disambiguating the matching modes, making parameter usage unambiguous.

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

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

The description clearly states the action ('Release a claimed quest') and the resource ('quest'), with a specific purpose ('so it's open for others again'). It also specifies matching by 'exact id (quest_id) or title prefix', which distinguishes it from siblings like wyrm_quest_claim and wyrm_quest_complete. This is precise and agent-actionable.

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

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

The description implies usage context: use when a quest is claimed and you want to make it available. It names the matching methods (exact id or title prefix) but does not explicitly state when to use alternative tools (like wyrm_quest_update for modifications). Since siblings are present, a clearer when-not-to-use would elevate this, but the provided context is sufficient for an agent to infer the primary scenario.

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 lookup semantics and updatable fields but leaves critical behaviors undisclosed: multiple title-prefix matches, id-versus-title precedence, omitted-field preservation, and no-match 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?

A single, well-structured sentence front-loads the action and object, then gives the lookup strategy. No filler or redundant restatement.

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 mutation tool with no annotations and no output schema, this description is too thin. It lacks guidance on multiple title-prefix matches, no-match errors, field preservation, and how to construct a minimal valid call given that the schema declares no required 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 schema already documents quest_id and workspace; the description adds that title is used for prefix matching and that priority/status are the updatable fields. However, it does not clarify that at least one identifier is required or whether omitted status/priority fields remain unchanged.

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 ('Update') and resource ('a quest'), and narrows the operation to priority and/or status. It also specifies two lookup strategies (exact quest_id or title prefix), which clearly distinguishes it from generic quest add/list/complete 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?

Description implies use when a quest's priority or status needs changing, and offers a choice between exact id and title-prefix lookup. However, it never names sibling alternatives or explicitly states when to prefer this tool over wyrm_quest_complete or wyrm_quest_release.

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. It does transparently describe its hybrid ranking approach and conceptual retrieval behavior. However, it does not explicitly state that this is a read-only operation, how results are ordered, or what happens with workspace scoping, 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 two concise sentences. The primary action and resource are front-loaded, and the second sentence earns its place by clarifying the ranking behavior. There is no wasted wording or redundancy.

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

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

Given only three parameters, all fully schema-documented, and no output schema, the description gives enough context about what is recalled (memory artifacts) and how retrieval works. It could be more explicit about the returned structure or ordering, but for a retrieval tool of this simplicity it is largely 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 description coverage is 100%, so the schema already documents all three parameters. The description adds a useful link between the 'query' parameter and 'current task', but provides no additional meaning for 'limit' or 'workspace' beyond what the schema already states.

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 ('recall') and a specific resource ('memory artifacts: lessons, patterns, reasoning traces'), and explicitly contrasts with keyword matching by mentioning hybrid semantic + full-text ranking. This makes the tool's intent clear and helps differentiate it from a plain search sibling.

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

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

The phrase 'for the current task' gives context for when the tool is appropriate, and 'not just keyword matches' hints at preferring this over pure keyword search. However, it never explicitly states when to use this tool versus alternatives like wyrm_search, nor does it give exclusion criteria or when-not-to-use guidance.

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

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

With no annotations, the description carries the full behavioral burden. It indicates a write operation ('store') but provides no details about idempotency, overwrite behavior, return value, workspace scoping, or side effects. This is minimal disclosure beyond the verb 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 a single, front-loaded sentence with no fluff. Every word contributes to the core purpose, and the artifact-kind list adds useful specificity without excess length.

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 an 8-parameter storage tool with no output schema or annotations, this description is incomplete. It lacks any mention of return behavior, storage semantics, interaction with recall/search, or workspace defaulting, leaving the agent to guess important operational context.

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 38%, so the description must compensate. It does not, beyond listing the artifact kinds that map to the 'kind' enum. The meanings of required fields like 'problem' or fields like 'why', 'solution', and 'confidence' are left entirely to inference from parameter names.

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 ('Store') and a well-defined resource ('distilled knowledge artifact'), and enumerates the artifact kinds. This clearly states what the tool does, though it does not explicitly distinguish it from siblings like wyrm_capture or wyrm_vault_put.

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 alternatives such as wyrm_capture or wyrm_recall. The description states the action but provides no context for selection, 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 must carry the burden of behavioral disclosure. It only says 'full-text search,' implying a read operation, but does not explicitly confirm non-destructiveness, describe return format, or mention any limitations or side effects. This is a significant gap for a search tool that could have performance or data-exposure 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 a single, efficient sentence that front-loads the tool's purpose with zero unnecessary words. It is perfectly concise and well-structured.

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 is incomplete. It does not state what the search returns (e.g., IDs, full objects, snippets), how results are ordered, or any pagination details. The only contextual detail (workspace scoping) comes from the schema, not the description. An agent would lack critical information to interpret results 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 schema already provides descriptions for type, limit, and workspace, covering 75% of parameters. The description adds no parameter-specific guidance beyond the schema; it does not explain search syntax or the nature of the query parameter. Since schema coverage is high, the baseline is 3, and the description 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 clearly identifies the action (full-text search) and the resources (truths, quests, artifacts). It is specific enough to understand the tool's core function, but it does not explicitly differentiate from sibling tools like wyrm_recall or the various getters, so it lacks the comparative distinction needed for 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 no guidance on when to use this tool versus alternatives. It does not mention scenarios where a targeted getter (e.g., wyrm_truth_get) would be preferable or when full-text search is the appropriate choice. The workspace parameter description offers some context but no tool-selection advice.

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 has to carry the behavioral burden, and it does disclose what is loaded and that focus biases memory. However, it does not say whether the call is read-only, whether it mutates session state, or what the agent should expect back, which matters for a system-level priming 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?

Two sentences with every part contributing: the primary purpose and contents are front-loaded, followed by timing and an analogy. No filler or repetition of schema details.

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

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

For a simple two-optional-parameter tool with no output schema, the description plus schema covers what the tool loads and when to call it. It misses an explicit note on return behavior/side effects and should address the sibling wyrm_session_rehydrate to remove ambiguity, but overall an agent can 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 coverage is 100%, so focus and workspace are already well documented. The description adds a small behavioral note that focus selects the most relevant memory, but workspace requires no extra clarification; given the high schema coverage, 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?

The description names a specific verb and resource: it loads this account's working context at session start, enumerating ground truths, open quests, active failures, and optionally memory. It is clear but does not explicitly distinguish itself from the sibling wyrm_session_rehydrate, and its 'cloud equivalent of Claude Code's session rehydrate' phrasing actually risks colliding with that sibling's 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?

'Call this first' and 'at the start of a session' give an explicit, concrete trigger for using the tool. It does not state when not to use it or name alternatives such as wyrm_recall or wyrm_session_rehydrate, so it falls short of full 5-level 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 behavioral disclosure burden. It clearly conveys that the tool is a read/synthesis operation ('Assemble a briefing') and lists what it will produce. It does not explicitly state side-effect-freedom or permission requirements, but the briefing framing strongly implies a non-mutating 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 efficient sentence that front-loads the core purpose, enumerates the return content, and includes the usage guidance and sibling differentiation. Every clause earns its place; there is no filler or redundant restating of the tool name.

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

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

There is no output schema, so the description must explain the shape of what is returned; it does so by listing ground truths, open quests, active dead-ends, and recent decisions. It also communicates scope and timing. The only gap is the lack of detail on result format or ordering, but the provided categories are enough for an agent to invoke 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% for the single optional 'focus' parameter, which already explains its meaning. The tool description does not add new parameter-level detail, but it does not need to because the schema fully covers the parameter. Baseline 3 applies.

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

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

The description uses a specific verb ('Assemble'), a clear resource ('cross-workspace briefing'), and enumerates the content types it covers. It also explicitly distinguishes itself from wyrm_session_prime, making its purpose unambiguous even among many 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 states exactly when to use it: 'at the very start of a session or when picking up cold.' It also names the narrower alternative, wyrm_session_prime, and explains why this tool is broader, giving clear when-to-use versus when-to-use-other 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 of behavioral disclosure. 'Summary counts' implies a read-only operation, but the description does not explicitly state that it has no side effects, does not mention authentication or account requirements, and does not describe what kind of counts are returned. This is a meaningful gap for an unannotated 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 a single concise sentence with no filler or redundant information. It front-loads the core function—summary counts—and the scope, making it easy to parse quickly.

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

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

With no output schema, the description should clarify what the returned summary counts actually contain, but it only says 'summary counts of ... memory.' The account scoping and zero-parameter invocation make the tool easy to call, but the lack of detail about the result format and the meaning of 'hosted Wyrm Cloud memory' leaves gaps for an agent deciding whether this tool fits the task.

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 empty and there are no parameters to document, so the baseline of 4 applies. The description adds relevant scoping by indicating the counts are for 'this account's' memory, which removes ambiguity about whose data is being summarized.

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 tool as returning summary counts scoped to this account's hosted Wyrm Cloud memory, which distinguishes it from the quest, vault, and failure siblings. It is a noun phrase rather than an explicit verb+resource construction, and it does not explicitly differentiate itself from sibling tools, but the meaning is reasonably 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 description provides no guidance about when to use this tool instead of alternatives such as wyrm_vault_list, wyrm_search, or wyrm_workspaces. There is no mention of scenarios where this tool is preferred or where a sibling should be used instead.

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

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

With no annotations, the description carries the transparency burden. It discloses the core read-only behavior via 'List' and mentions optional filtering, but it does not state the workspace default scoping behavior, the response shape, or category matching semantics. The description is not misleading, but it leaves several behavioral details unspoken.

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, front-loaded with the verb and resource, and the filter options are stated compactly at the end. Every word earns its place for a tool of this simplicity.

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

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

This is a low-complexity tool with no required parameters and no output schema, so the description is minimally viable: an agent can call it with no arguments or with filters. However, it omits the default workspace behavior and does not describe what the returned list looks like, and category semantics remain underspecified. A bit more context would materially improve 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 documents 'workspace' well, but 'category' is only a bare string with no description. The tool description adds the useful meaning that both parameters are optional filters and can be combined ('and/or workspace'). It does not define acceptable category values or exact-match behavior, so parameter semantics are only partially enriched 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 states a specific verb ('List') and a specific resource ('stored ground truths'), and identifies the optional filters: category and workspace. This clearly distinguishes it from write-like siblings such as wyrm_truth_set and from other list tools that target different resources. Even without a title, an agent can tell exactly what this tool does.

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 use case is implied: call this tool when you need to enumerate ground truths, optionally narrowed by category or workspace. However, it gives no explicit exclusions or pointers to alternatives such as wyrm_recall, wyrm_search, or wyrm_vault_list, so the agent must infer when this is the right choice among siblings.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose durability and upsert behavior ('or update'), but it omits side effects, auth expectations, reversibility, and what happens to an existing truth with the same key/category.

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 with no filler and front-loads the core action. It is efficient, though the efficiency comes at the cost of omitted operational detail.

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

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

For a tool with no annotations, no output schema, and 30 sibling tools, the single sentence is not complete enough. It does not clarify the semantics of 'ground truth', how it differs from related memory/vault tools, or what the caller should expect after the call.

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

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

Schema description coverage is only 25% (workspace only), yet the description adds no meaning for category, key, or value. It implies a keyed truth record, but it does not explain what each parameter means or how they relate, so it does not compensate for the missing 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 uses a specific verb ('Record (or update)') and names a concrete resource ('durable ground truth'), so an agent can infer this is a persistent write/update operation. It does not explicitly contrast with siblings like wyrm_remember or wyrm_vault_put, so it gets partial credit rather than full.

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 when-to-use or when-not-to-use guidance is provided, and none of the siblings are named as alternatives. 'Durable ground truth' hints at a category of data, but the description leaves the agent to infer when this tool is preferred over wyrm_capture, wyrm_remember, or wyrm_vault_put.

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 available, the description carries the full burden of behavioral disclosure. It clearly communicates the most critical trait: the deletion is permanent. It also scopes the action to the account's vault. It omits minor details like auth requirements and behavior when the named secret does not exist, but the core destructive behavior is transparent.

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

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

The description is a single sentence with no filler. It front-loads the action and consequence, then the resource and key. Every word contributes 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?

For a simple two-parameter delete operation, the description gives enough information to invoke the tool correctly: the required identifier, the permanence of the action, and the target scope. It could additionally explain workspace scoping or return behavior, but those are minor gaps rather than blockers.

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 meaning to the `name` parameter by identifying it as the secret's name, which compensates for the schema lacking a description on that field. It does not add anything about `workspace`, but the schema already describes that parameter and its default behavior, so the combined coverage is adequate.

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 ('Permanently delete'), the resource ('a secret from this account's vault'), and the selection method ('by name'). This sharply distinguishes it from sibling tools like wyrm_vault_get, wyrm_vault_list, and wyrm_vault_put.

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 but gives no guidance on when to use it, when not to use it, or which alternatives might be more appropriate. It does not mention preconditions, caveats, or related read/update 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?

No annotations are present, so the description carries the disclosure burden. It reveals that the operation returns the secret as plaintext and warns to handle it carefully, which is a meaningful behavioral safety note. It does not go into permissions or missing-name behavior, but for a simple retrieval tool this is largely adequate.

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

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

Two short sentences: the first states the action and scope, the second gives a necessary security warning. No 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 two-parameter tool with no output schema, the description covers the core return behavior (plaintext secret) and flags sensitivity. Workspace semantics are supplied by the schema, so nothing essential is missing, though error/not-found behavior is unspecified.

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?

Tool description adds that name is the secret's name, which the schema leaves undocumented, and workspace is already explained in the schema. With 50% schema coverage the description partially compensates, but doesn't add syntax or formatting details for either parameter.

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

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

States a precise action ('Retrieve and decrypt') and resource ('a secret from this account's vault by name'), and clarifies the result with 'Returns the plaintext value.' This separates it from sibling vault_put/delete/list operations by verb and scope.

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 it: when a named vault secret is needed. It does not explicitly contrast with alternative retrieval tools like wyrm_recall, wyrm_search, or wyrm_truth_get, and gives no 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?

No annotations are provided, so the description carries the behavioral burden. It adds a clear, non-obvious guarantee that secret values are never returned, and clarifies the output category. It does not mention pagination, errors, or side effects, but 'List' implies a read-only operation and the return scope is described.

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 information-dense sentence, with the primary action and resource front-loaded and the important negative guarantee in a short follow-up. There is no redundant 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?

For a simple list tool with one optional parameter and no output schema, the description adequately explains what is returned (names and non-secret hints) and what is never returned (secret values). The workspace behavior is covered by the schema, so nothing critical 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 description coverage is 100% for the single optional parameter, workspace, and the schema already explains its default and purpose. 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 a specific resource ('secret NAMES... in this account's vault'). It also explicitly states 'Never returns secret values', which distinguishes it from vault_get and other vault 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?

It gives clear context for the listing use case: you call this to get secret names and non-secret hints. The 'Never returns secret values' statement is a useful exclusion, telling an agent not to use this tool when it needs actual secret values, though it does not name vault_get explicitly.

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 and does so excellently. It discloses encryption at rest with AES-256-GCM, per-account keying, the important non-zero-knowledge caveat for cloud-tier, and that re-putting a name overwrites the existing secret.

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

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

Three dense sentences with no filler. The core purpose comes first, followed by the encryption details and the critical overwrite caveat, all in a compact and scannable structure.

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 four-parameter write tool with no annotations or output schema, the description covers the essential behavior: what is stored, how it is protected, the security caveat, and the overwrite semantics. It could add return-value or error behavior, but that is a minor omission given the tool's simplicity.

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 value beyond the schema by clarifying that the secret is keyed by name and that re-putting a name overwrites the stored value. It does not add detail for hint or workspace, but the schema already documents those adequately.

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?

Clearly identifies the action ('Store'), the resource ('vault'), and the content type ('encrypted secret'), with examples of expected values. It does not explicitly contrast with sibling tools like wyrm_vault_get or wyrm_remember, but the vault-specific, encrypted-secret framing makes its role 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 description implies this is for storing secrets, but it gives no explicit guidance on when to choose this tool over alternatives. It does not mention when not to use it, or name related tools such as wyrm_vault_list, wyrm_vault_get, or wyrm_remember.

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 discloses the scoping ('in this account'), the output feature ('item counts'), and non-destructive intent via 'List', but it does not mention permissions, ordering, pagination, or exact return structure. This is adequate for a simple read-only listing tool, but leaves 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?

The description is two short sentences with no filler. The first sentence states the action and output, and the second provides conceptual context that helps the agent understand why workspaces matter. It is front-loaded and 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 zero-parameter list tool with no output schema, the description covers the essential information: what is listed, at what scope, and what output detail is included. It could be slightly more complete by stating return format or how this relates to other wyrm tools, but given the tool's simplicity, the remaining gaps are 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?

The tool has no parameters, so the description correctly needs to add no parameter-level detail. The described account scope and item-count output provide the only meaningful invocation context, which fits the no-parameter schema baseline.

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

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

The description uses a specific verb ('List'), identifies the resource ('workspaces (project partitions)'), and adds the output characteristic ('with item counts'). It also clarifies the concept by explaining that workspaces isolate separate work streams, which distinguishes this tool from account-level quest or vault tools among the 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 gives useful context about what workspaces are and implies that this tool is for seeing the account's top-level project partitions. However, it does not explicitly state when to prefer this over related tools, nor does it mention any alternatives or exclusions.

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