Wyrm

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

With no annotations, the description must carry the behavioral burden, and it does disclose the important trait: results are capped at 50 unless a limit is supplied, so the agent knows output can be truncated. The read-only nature is conveyed by "List," but there is no mention of permissions, ordering, or rate 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?

Three short sentences, front-loaded with scope and the sibling distinction before the operational details. Every clause earns its place, and nothing is repeated from the schema.

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

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

An output schema exists, so return-shape explanation is unnecessary; the description supplies what structured fields don't, namely cross-workspace scope and the truncation behavior. For a two-parameter read-only list tool, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the limit parameter raises the otherwise hard 50-result cap, and status is framed as an optional filter. That cap-versus-parameter relationship is not visible in the schema text alone.

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 (List) and resource (quests) plus a precise scope: across ALL workspaces for the account, explicitly contrasted with "the connection's default." That scope clause is what separates it from the sibling wyrm_quest_list, so an agent can pick between them without opening either schema.

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

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

The description gives clear context for when this tool applies ("the account-wide view of open work") and notes the optional status filter. It never names wyrm_quest_list as the alternative or states when to prefer the narrower per-connection listing, so the routing guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full behavioral burden: it does disclose the batching trait (multiple items in one call) and that entries are durable/persisted, which are traits beyond the schema. It says nothing about whether capture is additive versus merging, idempotency and duplicate handling, required permissions, or partial-failure behavior when only some arrays are supplied — the main things an agent needs before firing a mutation.

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, roughly forty words, with the core action front-loaded and usage guidance immediately after. Every clause does work — 'ONE call' sets the batching contract, 'don't wait to be asked' sets the trigger, 'signal, not chatter' sets the quality filter. 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?

Output schema exists, so return values need not be explained, and the schema covers parameters fully; the description fills the remaining gaps by defining payload categories and proactive timing. The residual weakness is that a multi-item write tool with zero annotations leaves merge/dedup semantics and workspace scoping implicit.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, and the description intentionally mirrors them in plain language ('ground truths', 'lessons/decisions', 'quests'). The workspace parameter is never mentioned, and no format or syntax hints are added beyond the schema, so 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?

States a specific verb and resource with scope: batch-save durable knowledge in ONE call, and enumerates the three payload groups (truths, lessons/decisions, quests) that match the schema's arrays. The word 'batch' and 'ONE call' loosely imply contrast with single-item siblings like wyrm_quest_add, wyrm_truth_set, and wyrm_remember, but none is named, so differentiation is left to inference.

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 triggering context: use it as decision-grade facts emerge and don't wait to be asked, plus a filter rule ('capture signal, not chatter'). It never names the granular alternatives (wyrm_remember, wyrm_quest_add, wyrm_truth_set) or says when to prefer those over batching, so the routing burden stays on the agent.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the scope of content pulled in (ground truths, matching artifacts, open quests), which implies a read-only aggregation, but says nothing about permissions, cost/token budget, or whether anything is persisted — notable gaps for a memory-spanning 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?

A single front-loaded sentence with an efficient colon-delimited list of the three sources. Every clause earns its place, with no redundant restatement of the title or 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?

The output schema exists and covers return values, so the description needn't explain results. However, with no annotations and an undocumented required 'task' parameter, the definition leaves the agent short of what it needs to invoke the tool confidently.

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%: 'workspace' is documented in the schema, but 'task' — the sole required parameter — has no description anywhere. The prose does not compensate by explaining what a 'task' string should contain (a prompt, an id, a query), leaving the primary input under-specified.

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

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

The description gives a specific verb ('Assemble') and a concrete resource ('task brief from this account's memory'), then names the three content categories it aggregates (ground truths, artifacts, open quests). An agent can distinguish it from raw siblings like wyrm_search or wyrm_recall, though it never explicitly names an alternative.

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

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

There is no when-to-use or when-not-to-use guidance and no routing to alternatives such as wyrm_search, wyrm_recall, or wyrm_session_prime. The agent must infer from the name that this is the aggregation entry point rather than a primitive lookup.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the traceability intent but omits whether the referenced truths must already exist, what happens on invalid refs, permission requirements, or how this relates to the invalidation workflow.

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

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

A single, front-loaded sentence that states the action and its payoff with no filler. It is appropriately sized, though it could carry one more clause of operational detail at no real cost.

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

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

An output schema exists, so return values need not be explained, and the core purpose is stated. For a no-annotation mutation tool with two undocumented parameters, however, more behavioral context is warranted than is provided.

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 50%; the 'because' and 'workspace' params are documented in the schema, while 'decision' and 'rationale' are not. The description gestures at 'decision' and 'ground truths' but leaves the distinction between 'decision' and 'rationale' unexplained, so it only partially compensates.

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

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

The description gives a specific verb ('Record') and resource ('a decision and the ground truths it rests on'), making the operation clear. It does not, however, explicitly distinguish itself from close siblings like wyrm_capture, wyrm_remember, or wyrm_decision_trace, which a reader must infer.

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 the value ('so the rationale survives and can be traced when a truth later changes') but never states when to use this versus alternatives such as wyrm_remember or wyrm_capture, nor any prerequisites. Usage is only implied.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose the semantic model (a dependency cascade) and the read-like nature implied by 'Show'. It says nothing about whether results are paginated, whether the truth must already exist, or what happens for an unknown ref, which are meaningful gaps 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?

Two tight sentences with the core purpose front-loaded and no filler. The trailing format reminder duplicates the schema slightly, but it is short and harmless.

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

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

An output schema exists, so return values need not be explained, and both parameters are covered by the schema. The description supplies the dependency semantics and the ref format, leaving only edge-case behavior (missing truth, empty cascade) unaddressed.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, including the 'category.key' format. The description restates that format for 'truth' but adds no syntax, constraints, or behavior beyond it, so the 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?

States a specific verb ('Show') and a precisely-scoped resource ('the decisions that depend on a given ground truth'), and the parenthetical 'downstream cascade' pins the direction of the relationship. It implicitly distinguishes itself from the sibling wyrm_decision_upstream, though it never names that sibling explicitly.

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

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

The phrase 'the decisions to revisit if that truth changed' gives a concrete use case, which is better than nothing. However, no alternative is named and no condition is given for choosing this over wyrm_decision_upstream, wyrm_decision_trace, or wyrm_decided_because, so usage remains implied.

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

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

No annotations exist, so the description carries the full burden, and it does disclose the important state model: the decision 'stays in history but is flagged in traces', i.e. a soft invalidation rather than a hard delete. It omits any statement about permissions, reversibility, or what happens when a title prefix matches multiple decisions.

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

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

Two dense sentences, zero filler. The core action comes first, followed by persistence behavior and matching semantics; every clause adds information an agent needs.

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

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

An output schema exists, so return values need no explanation, and the mutation's soft-delete behavior is disclosed. The notable remaining gap is ambiguity handling for prefix matching and whether an invalidated decision can be restored.

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%: workspace and superseded_by are described in the schema, but the required 'decision' parameter is undocumented there. The description compensates by explaining the matching semantics ('matches by decision title prefix') and the optional supersede recording, which is genuine meaning 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?

States a specific verb+resource: mark a decision invalidated/superseded, with a parenthetical example of the triggering scenario. It is distinguishable from the many sibling read tools (wyrm_decision_trace, wyrm_decision_upstream) and from wyrm_truth_set, though it does not explicitly name a sibling it overlaps with.

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

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

Gives a clear triggering context — 'e.g. a ground truth it rested on changed' — which tells the agent when this tool applies. There is no explicit when-not guidance or named alternative (e.g. recording a new decision via wyrm_remember instead), so it falls short of a 5.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses what each mode yields ('what to revisit when it changes', 'what they rest on'), but never states that this is a non-mutating read, nor anything about permissions, rate limits, or result size — leaving the safety profile to inference from the word 'trace'/'list'.

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 compact sentences, front-loaded with the purpose and then the two branching behaviors. Every clause carries information; nothing is padded or repeated from the schema.

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

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

For a two-parameter, zero-required, read-oriented tool with an output schema (which handles return-value documentation), the description covers both call modes adequately. The remaining gap is only the unmentioned `workspace` scoping and the lack of differentiation from sibling decision tools.

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

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

Schema description coverage is 100%, so the schema already defines both parameters, establishing a baseline of 3. The description adds functional meaning to `truth` (its role in finding dependents worth revisiting) but says nothing about `workspace` scoping beyond what the schema provides.

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

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

The description states a specific verb ('trace') and resource ('decisions'), and its two operating modes are concrete: dependents-of-a-truth vs. recent-decisions listing. It does not, however, distinguish itself from overlapping siblings such as wyrm_decision_downstream, wyrm_decision_upstream, or wyrm_decided_because, which an agent would need to disambiguate against.

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 conditional guidance for both invocation paths: pass `truth` to find items to revisit, pass nothing to list recent decisions. There are no explicit exclusions or pointers to the seemingly overlapping decision-graph siblings, so the routing is clear but incomplete.

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

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

With no annotations, the description carries the full burden. It usefully discloses that each truth is returned with its CURRENT value (i.e., a live snapshot, not a historical record), which is meaningful context, but it says nothing about read-only nature, permissions, or scoping side effects beyond the schema. A 3 reflects some added value but incomplete behavioral disclosure.

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

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

A single dense, front-loaded sentence that packs purpose, return semantics, and the matching rule. No wasted words, though the em-dash aside slightly slows the read.

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 an output schema present and 100% param coverage, the description needn't explain return values; it still adds useful conceptual framing about why upstream truths matter. It is complete enough for correct invocation, though sibling differentiation could be sharper.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema (including the prefix-matching hint for 'decision'). The description's 'Match by decision title prefix' largely restates what the schema says, so baseline 3 is appropriate.

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

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

States a specific verb+resource: shows the ground truths (upstream dependencies) a decision rests on, and clarifies intent ('so you can tell whether the basis still holds'). The 'upstream' framing reasonably distinguishes it from wyrm_decision_downstream, but it does not explicitly differentiate from related siblings like wyrm_decided_because or wyrm_decision_trace.

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

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

Provides clear when-to-use context: validating whether a decision's basis still holds via current values. It also gives a selection guide ('Match by decision title prefix'). However, it names no explicit alternative or exclusion condition, leaving the agent to infer when to prefer wyrm_decision_downstream or wyrm_decided_because.

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. 'Check' and 'surfaces past dead-ends' imply a read-only, non-mutating lookup, and the token-saving intent explains why to call it, but there is no explicit statement of read-only semantics, permission needs, or rate limits.

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

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

Two tight sentences, front-loaded with the imperative timing cue 'BEFORE', so the critical instruction is the first thing read. The second sentence is slightly salesy but earns its place by explaining the payoff and the tool's counter-pattern framing.

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

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

An output schema exists, so return values need not be explained, and the schema fully documents both parameters. What remains is a clear pre-flight purpose and trigger; only explicit sibling routing and any read-only confirmation are missing.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema; baseline is 3. The phrase 'for this account' loosely corresponds to the workspace scoping parameter but adds no syntax, format, or defaulting detail 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?

Names a specific verb (check) and resource (past failures for a given approach), and frames it as a pre-flight lookup rather than a listing or write. It implicitly separates itself from siblings like wyrm_failure_list and wyrm_failure_record, but never names those alternatives explicitly.

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

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

Gives a clear temporal trigger: 'BEFORE trying a fix or approach.' That is strong when-to-use guidance. It does not, however, name the sibling to use afterward (e.g., wyrm_failure_record to log a new dead-end) or state any when-not condition.

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

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

With no annotations, the description carries the full burden. It usefully discloses that results are filtered to 'active (unresolved)' failures and frames them as a 'do not repeat' set, which conveys intent. It says nothing about permissions, pagination, or how the resolved set is excluded, so gaps remain.

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 compact sentence with the key scoping qualifier front-loaded. Nothing is wasted, though the trailing 'do not repeat set' aside is slightly informal rather than purely functional.

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

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

For a simple one-parameter list tool with an output schema present, the description covers purpose and filtering adequately. The only missing element is explicit routing against the six sibling failure/quest tools.

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

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

Schema description coverage is 100%, so the single workspace parameter is already fully documented in the schema. The description adds no syntax, default, or format detail beyond that, making 3 the correct 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?

States a specific verb (List) and resource (active/unresolved failures) scoped to the account, and the parenthetical 'unresolved' narrows the meaning beyond just 'failures'. It does not, however, name or distinguish itself from its close siblings wyrm_failure_check, wyrm_failure_record, or wyrm_failure_resolve.

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

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

The description implies a read use case via 'the current do-not-repeat set,' but gives no explicit when-to-use, no exclusions, and no routing to alternatives such as wyrm_failure_check or wyrm_failure_resolve. An agent must infer the choice from names alone.

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

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

With no annotations, the description carries the full behavioral burden and it does disclose the key trait: this is a persistent write whose effect is that the approach is blocked on future attempts (the 'counter-pattern firewall'). It does not cover permissions, reversibility/removal (a sibling wyrm_failure_resolve exists), or deduplication of repeated failures, so it falls short of full disclosure.

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

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

A single tight sentence front-loads the action and its effect, with the parenthetical framing the mechanism and a second clause enumerating the payload. No filler sentences.

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

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

For a 4-parameter, non-nested tool with an output schema (so return values need no explanation), the description plus schema cover what to record and why. It stops short of explaining the workspace scoping semantics or how blocked entries are later resolved, which a caller of this mutation tool would benefit from.

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 properties already define scope, target, workspace and description; the baseline here is 3. The sentence 'Capture the scope, what it was tried on, and what went wrong' restates three of those fields but adds no format, granularity or naming-convention detail 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?

States a specific verb and resource (record a FAILED approach) and adds the consequence (blocked next time), which clearly separates it from wyrm_failure_list, wyrm_failure_check and wyrm_failure_resolve. It never names a sibling explicitly, so the routing is inferable but not spelled out.

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 it is blocked next time' implies the use case (call this after a failed attempt to prevent repetition), but there is no explicit when-to-use statement, no ordering guidance relative to wyrm_failure_check, and no note about when NOT to record. Usage is implied rather than prescribed.

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 does disclose the behavioral effect (the failure stops blocking once marked), but says nothing about reversibility, whether the record is deleted or just flagged, or any permission/auth requirements for this mutation.

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

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

A single front-loaded sentence with the verb first and the clarifying parenthetical earning its place; 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?

For a low-complexity one-parameter state-change tool with an output schema (so return values need not be explained) and full param coverage, the description is nearly complete. It could add a note on reversibility or required permissions, but 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?

Schema coverage is 100% and the single 'id' parameter is fully documented (including its source: wyrm_failure_list). The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource (mark a recorded failure resolved/superseded) and the consequence ('no longer blocks'), which cleanly separates it from wyrm_failure_record/check/list. It stops short of explicitly naming its sibling tools, but the action 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?

Provides a clear semantic condition for use — the underlying issue is fixed or the approach now works — which tells the agent when resolving is warranted. It does not name alternatives (e.g. leaving via wyrm_failure_record or re-recording) or state when-not to use, so it falls short of a full 5.

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

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

With no annotations, the description carries the full burden. The word 'open' hints that the created entity defaults to an open status, which is a small disclosure beyond the name. However, it says nothing about permissions, duplicate handling, default priority, or whether priority is mutable later, leaving mutation behavior opaque.

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

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

A single front-loaded sentence with no wasted words. It is appropriately sized for the amount of information it conveys, though the terseness is partly a symptom of under-specification rather than disciplined editing.

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

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

An output schema exists, so return values need not be explained, but for a 4-parameter mutation tool with zero annotations, 25% schema coverage, and no usage guidance, the description leaves too much unspecified for an agent to call it reliably in a crowded sibling set.

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

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

Schema description coverage is only 25% – only 'workspace' is documented. Title, detail, and the priority enum carry no explanation in either the schema or the description, and the description adds nothing about them (e.g., whether detail is a body, what a missing priority defaults to). The description does not compensate for the coverage gap.

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

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

States a specific verb (Add) and resource (quest), and glosses quest as 'a tracked goal or task', which helps an agent understand the domain object. It does not explicitly distinguish itself from siblings like wyrm_quest_update or wyrm_quest_claim, but the create verb is unambiguous enough to route correctly.

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

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

No guidance on when to use this versus wyrm_quest_update, wyrm_quest_claim, or other quest siblings. It does not state prerequisites, nor whether it is the entry point of a claim/complete workflow. The agent must infer usage entirely.

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 supplied, so the description carries the full behavioral burden, and it does disclose the most important trait: the operation refuses when another agent already holds the claim, overridable only via `force`. It omits claim lifetime/expiry, concurrency/race behavior, and whether the claim is visible across workspaces, which for a coordination primitive with zero annotation coverage leaves gaps.

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

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

Three short sentences: what it does and why first, matching semantics second, conflict/override rule third. No filler, no repetition of the name, and the most decision-relevant fact (the claim conflict) sits late but is still compact.

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

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

An output schema exists, so return values need not be explained here, and the description adequately covers invocation matching and conflict handling for a 5-param coordination tool. It is slightly thin on claim lifecycle (does a claim expire or persist?) which matters for a multi-agent lock, but otherwise 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?

With 60% schema coverage, two parameters (title, force) have no schema text; the description compensates by defining title as a prefix match and force as the override for an existing claim. It adds no meaning for `by` or `workspace` beyond their schema descriptions, but the gap-filling on the undocumented params is genuine added value.

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

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

Names a specific verb (claim) and resource (an open quest) and immediately frames the purpose as multi-agent coordination 'so others know it's being worked.' That framing distinguishes it cleanly from siblings like wyrm_quest_release, wyrm_quest_complete, and wyrm_quest_list without needing to open any schema.

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

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

States the matching mode (exact quest_id or title prefix) and the refusal condition with its `force` escape hatch, which is real when-to-use guidance. It stops short of pointing at the sibling tools to call instead (e.g. release/complete) once the quest is done, so no explicit alternative routing.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation is a state change ('mark completed') but says nothing about permissions, reversibility, or what happens when a title prefix matches multiple quests — a real ambiguity risk given prefix matching.

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 tight sentence, front-loaded with the action and the two targeting options; nothing extraneous. Slightly terse given the mutation semantics that remain unexplained, but structurally clean.

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

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

An output schema exists so return values need not be described. However, for a no-annotation mutation tool, the description omits ambiguity handling and side-effect details, leaving it only minimally 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 title, quest_id, and workspace. The description restates the id-vs-prefix distinction but adds no syntax or format details beyond what the schema provides, so 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?

Specific verb ('Mark ... completed') plus resource ('quest') and the two identification modes. An agent knows what the tool does, but the description doesn't explicitly contrast it with sibling wyrm_quest_update, which also mutates quests.

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 explains the two ways to target a quest (exact quest_id or title prefix), which implies usage, but gives no explicit when-to-use/when-not guidance or alternatives such as wyrm_quest_update for non-completion 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, the description carries the full burden. It does disclose a useful behavioral trait beyond the schema: the result is capped at 50 unless a limit is given. It does not state read-only semantics, ordering, or what happens when status is omitted (the schema enum includes 'all', suggesting a default).

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, zero filler, with the primary action and its scoping stated first and the pagination caveat second. Every clause earns its place.

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

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

An output schema exists, so return-value explanation is unnecessary. The description covers filtering and the result cap, leaving only minor gaps such as default status behavior and how it relates to wyrm_all_quests.

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 67%, so the schema covers part of the surface (workspace has a full description, limit just 'Default 50'). The description adds the cap behavior tied to limit and names the status/workspace filters, but adds nothing about the status enum values or default behavior. Baseline 3 fits.

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

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

States a specific verb and resource (list quests) plus the optional filters, so an agent knows exactly what the tool returns. It does not, however, differentiate itself from the sibling wyrm_all_quests, which sounds like a near-synonym.

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 'optionally filtered by status and/or workspace' implies when the filters are useful, but there is no explicit guidance on when to pick this tool over wyrm_all_quests or how the two differ. Usage is left to inference.

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

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

With no annotations, the description carries the full burden. It usefully discloses the matching behavior (exact id vs. title prefix), but omits key behavioral traits: whether the caller must be the one who claimed the quest, what happens if the quest was never claimed, and how ambiguity is handled when a title prefix matches multiple quests.

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

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

Two short sentences, front-loaded with the action and its effect, then the matching rule. Nothing is padded or redundant.

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

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

An output schema exists so return values are covered, but for an unannotated mutation tool the description leaves out preconditions and error/ambiguity behavior for a prefix match. Adequate to call the tool, but an agent cannot predict the failure modes.

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 real value by specifying that 'title' is matched by prefix, which the schema does not state. However, it does not resolve the more important ambiguity: all three parameters are optional, and the precedence rule when both title and quest_id are supplied is left to 'Use instead of title' in the schema rather than explained.

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 (release) and resource (a claimed quest) plus the resulting state change ('open for others again'), which cleanly distinguishes it from the imperative siblings wyrm_quest_claim and wyrm_quest_complete. It does not explicitly name those siblings, so it falls short of the 5 bar for sibling differentiation.

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 it's open for others again' implies the scenario (undoing a claim you no longer need), but there is no explicit guidance on when to use this versus wyrm_quest_complete or wyrm_quest_update. No prerequisites or conditions are spelled out.

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 conveys partial-update semantics via 'and/or' and the dual targeting mechanism, but says nothing about what happens when a title prefix matches multiple quests, whether a nonexistent target errors, permission/auth requirements, or reversibility of a mutation.

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 tight sentence, front-loaded with the action and the two update fields, with the targeting detail trailing. 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?

An output schema exists, so return values need not be explained, and the low complexity of a field update is largely covered. Still, with zero required parameters and no annotations, the description should say what happens if neither quest_id nor title is supplied, and it omits workspace scoping entirely.

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 40%, so compensation matters. The description does add real semantics the schema lacks, notably that title matching is a prefix match ('start of its title'), and echoes the questId/id aliases already documented for quest_id. However, the workspace parameter is never mentioned and the update fields are not tied to the enum values, leaving gaps.

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 clear verb and resource ('Update a quest's priority and/or status') and names the exact mutatable fields, so the agent knows what changes. It does not, however, distinguish itself from the overlapping sibling wyrm_quest_complete, which also transitions status, leaving an ambiguity an agent must resolve itself.

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 sentence gives targeting guidance ('by its exact id (quest_id) or by matching the start of its title'), which is a usable identification rule. But it offers no when-to-use guidance relative to alternatives like wyrm_quest_complete, wyrm_quest_claim, or wyrm_quest_release, so the routing decision is left to inference.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully explains the hybrid semantic + full-text ranking mechanism, which is real behavioral context, but omits that this is a read-only operation, any permission/scoping caveats, or latency/limit behavior beyond what the schema states.

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

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

Two tight sentences with the core purpose front-loaded and the ranking behavior as supporting detail. Every clause earns its place with no filler.

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

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

An output schema exists so return values need not be explained, and all parameters are covered by the schema. The description adequately conveys what the tool retrieves, though for an unannotated tool it could say more about safety and scoping behavior.

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

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

Schema description coverage is 100%, so all three parameters (query, limit, workspace) are already documented. The description adds 'for the current task' as framing for the query parameter but no syntax, format, or default detail beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb (Recall) and resource (memory artifacts, enumerated as lessons, patterns, reasoning traces) scoped to the current task. The phrase 'not just keyword matches' implicitly contrasts it with the keyword-oriented wyrm_search sibling, but never names it, so differentiation is suggestive rather than explicit.

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

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

The description implies usage context ('for the current task', 'conceptually related memory') which suggests reaching for this when semantic recall is needed, but it never states when to prefer it over wyrm_search or wyrm_context_build/session_prime. The guidance is inferable rather than directive.

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

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

No annotations are provided, so the description carries the full burden, and it is a mutation tool. It never states persistence lifetime, dedup/overwrite behavior on repeat writes, required auth, or whether writes are idempotent. 'Distilled' hints that content should be curated rather than raw, which is the only behavioral signal offered.

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

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

One sentence, front-loaded with the verb and scope, with zero filler. It is tightly written, though at this level of schema complexity the brevity contributes to the gaps scored in other dimensions.

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

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

An output schema exists so return values need not be explained, but with 8 parameters, 38% description coverage, no annotations, and multiple near-sibling write tools, the description leaves an agent unable to decide when this tool is correct or how to fill the required fields meaningfully.

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% (3 of 8 properties documented: tags, workspace, confidence), so the description must compensate and does not. It adds nothing about problem, why, solution, or outcome, and the kind list merely restates the enum rather than explaining how each kind should be written.

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?

Specific verb ('Store') plus a named resource ('distilled knowledge artifact') and it enumerates the five kind values that match the schema enum, so the scope is legible. It does not differentiate from siblings like wyrm_capture, wyrm_truth_set, or wyrm_failure_record, which plausibly also persist content.

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 guidance at all: nothing says when to choose wyrm_remember over wyrm_capture (which sounds like the raw-input counterpart) or whether it should precede wyrm_recall/wyrm_search. The agent must infer the trigger from the tool name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing: no ranking behavior, no pagination/limit semantics, no statement that this is a read-only operation, and no note on the workspace-isolation behavior that the schema hints at. 'Full-text search' implies a safe read but this is left to inference.

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 tight sentence with the resource scope front-loaded and zero filler. It is efficient, though its brevity comes at the cost of the missing usage and behavior detail scored elsewhere.

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

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

An output schema exists, so return values need not be explained, and the schema covers the four parameters reasonably well. What remains missing is the relationship to sibling retrieval tools (wyrm_recall, wyrm_truth_get) and any note on default scoping, leaving the definition merely adequate.

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 75%, so the schema already documents the enum, the limit bound, and the workspace scoping. The description adds no additional meaning about query syntax, matching behavior, or how type/limit interact, so the baseline of 3 applies.

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

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

States a specific verb (full-text search) and names the exact resources searched (truths, quests, artifacts) scoped to the account. This is clearly distinguishable from mutation siblings like wyrm_remember or wyrm_quest_add, though it does not explicitly contrast itself with the more semantically-oriented wyrm_recall.

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

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

The description gives no when-to-use or when-not-to-use guidance, and never mentions the obvious alternative wyrm_recall or wyrm_truth_get. An agent must infer from the name alone that this is the keyword-search path rather than a semantic recall path.

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

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

Without annotations, the description carries the burden and does disclose the assembled contents and the conditional effect of 'focus' on memory recall. It implies a read-only load but does not explicitly address auth, side effects, or rate limits.

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 efficient sentences: the first states the purpose and contents, the second gives the priority directive. It is front-loaded and every clause earns its place.

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

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

Complete for a session-bootstrap tool with a rich schema and an output schema that covers return values. The only missing context is explicit sibling differentiation and when-not guidance, which are minor for this use case.

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

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

Schema description coverage is 100%, so both parameters are already well documented. The description reinforces their role in context assembly but adds no format or syntax detail beyond what the schema provides, making 3 the appropriate 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?

States a specific verb ('Load') and resource ('account's working context'), and enumerates what is included: ground truths, open quests, active failures, and relevant memory. It is clear but does not distinguish itself from siblings such as wyrm_session_rehydrate or wyrm_context_build.

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

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

Explicitly says 'Call this first' and anchors usage to 'the start of a session', which gives clear context. It does not state when not to use it or name a sibling alternative, so it falls short of full when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the scope and composition of the briefing, which is useful behavioral context, but says nothing about safety profile, permissions, or whether any state is written. Adequate but leaves clear gaps for a tool with zero annotation coverage.

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

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

Two sentences with zero waste; the scoping claim is front-loaded and the alternative-tool comparison follows immediately. Every clause earns its place.

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

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

An output schema exists, so return values need not be explained. The description covers purpose, scope, timing, and the sibling alternative, which is complete for a read-only aggregation tool.

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

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

Schema coverage is 100% and the single optional 'focus' parameter is fully described in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 for schema-covered parameters is appropriate.

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

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

States a specific verb (Assemble) and resource (cross-workspace briefing) and enumerates its contents: ground truths, open quests, active dead-ends, recent decisions. It explicitly contrasts itself with sibling wyrm_session_prime, so an agent can distinguish the two without opening either schema.

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

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

Gives explicit timing ("at the very start of a session or when picking up cold") and names the alternative with its selection condition (wyrm_session_prime scopes to one workspace). The agent knows both when to use this and when to prefer the sibling.

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. 'Summary counts' strongly implies a read-only aggregate operation and the zero-parameter schema makes it low-risk, but the description never explicitly asserts read-only behavior or says whether counts span all workspaces or just the current context.

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

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

A single front-loaded sentence with no filler. Every word earns its place and the resource is named immediately.

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

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

An output schema exists, so return values need not be described, and with zero params this simple stats tool needs little more. The only real gap is which dimensions the counts cover and whether they are account-wide or workspace-scoped.

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 takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and the empty schema is self-consistent with a stats call.

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

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

States a specific resource and scope: summary counts of this account's hosted Wyrm Cloud memory. It is distinguishable from siblings like wyrm_recall or wyrm_vault_list as an aggregate-stats read, though it never clarifies what is being counted (memories vs. quests vs. both).

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 guidance, no prerequisites, and no mention of alternatives among the ~30 sibling tools. The agent must infer that this is the tool for a high-level account overview.

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 full behavioral burden. "List" weakly implies a read-only operation, but nothing is stated about read-only safety, pagination/limits, authentication, or result ordering; with no annotations to lean on, this leaves the agent guessing about scope and constraints.

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

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

A single front-loaded sentence with no filler; the operation and filters come first. The "and/or" phrasing is slightly awkward but harmless, and there is no structural padding.

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

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

An output schema exists, so return values need no explanation, and the tool is low-complexity with only two optional params. However, in a large sibling set the description gives no routing guidance and leaves 'category' semantics undocumented, so it is adequate but with clear gaps.

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

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

Schema description coverage is 50% — 'workspace' is documented in the schema but 'category' is not. The description clarifies that both are optional filters, which adds modest meaning to the undocumented 'category', but it does not explain matching semantics (exact vs. substring) or valid category values, so it only partially compensates for the coverage gap.

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

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

States a specific verb ("List") and resource ("stored ground truths") with scope (optional category/workspace filters), so an agent immediately understands the operation. It does not, however, distinguish itself from the obvious sibling wyrm_truth_set or from the broader recall/search tools, and the name (get) vs description (list) mismatch is a minor wrinkle.

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 "optionally filtered by category and/or workspace" implies when filters are useful, but there is no explicit guidance on when to use this tool versus wyrm_search, wyrm_recall, or wyrm_truth_set, and no exclusions or prerequisites. Usage is only implied, which is minimum viable.

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 but discloses only two facts: writes are durable and the operation is an upsert. It says nothing about auth requirements, conflict/overwrite behavior when category+key already exists, or what 'durable' means versus the recall/remember siblings.

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

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

A single front-loaded sentence with no waste. It is terse rather than padded, though the terseness is under-specification rather than a virtue here.

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

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

An output schema exists so return values need not be explained, but for a mutation tool with no annotations, three unexplained required parameters, and 25% schema coverage, the description is far too thin to call correctly.

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

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

Schema description coverage is only 25% — just the optional workspace field. The three required parameters (category, key, value) have no schema descriptions and the description adds nothing about their semantics, such as whether category acts as a namespace or whether key is unique within a category.

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+resource pair ('Record (or update) a durable ground truth'), which is enough to know it writes a keyed fact. However, 'ground truth' is unexplained domain jargon, and nothing distinguishes it from siblings like wyrm_remember or wyrm_vault_put that plausibly also persist durable data.

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 statement of when to use this over wyrm_remember, wyrm_vault_put, or wyrm_capture, all of which sit in the same persistence neighborhood. The agent must infer the choice entirely from the tool name.

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

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

With no annotations, the description carries the full behavioral burden; it does disclose the key trait that deletion is permanent/irreversible, which is genuinely useful. However, it omits permission/auth requirements, behavior when the name does not exist, and whether the operation is idempotent.

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

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

A single front-loaded sentence with the destructive qualifier ('Permanently') placed first. 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?

An output schema exists, so return values need not be explained. For a destructive mutation tool with no annotations, the description should say more about irreversibility consequences, error cases, and workspace scoping; it covers only the core action and the permanence flag.

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%: the 'workspace' parameter is documented in the schema, but 'name' has no description. The phrase 'by name' weakly signals that name is the lookup key, but adds no format, uniqueness, or case-sensitivity detail, so the gap is only partially compensated.

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 (delete), a specific resource (a secret in this account's vault), and the lookup key (by name). This clearly separates it from sibling reads/writes such as wyrm_vault_get, wyrm_vault_list, and wyrm_vault_put without needing the schema.

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

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

The description gives no when-to-use guidance: it never says when deletion is appropriate versus overwriting via wyrm_vault_put, nor does it state prerequisites or what to do if the secret is absent. Usage must be inferred entirely from the tool name.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the value is decrypted and returned as plaintext and flags sensitivity ('handle with care'), but it omits whether access requires specific permissions, whether reads are audited, and what happens when the secret is missing or undecryptable.

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

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

Two tight sentences with the core action front-loaded and the cautionary note second. The 'Returns the plaintext value' clause partly restates what the output schema covers, but the security warning 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?

An output schema exists, so return-value explanation is not required. However, for a secrets-retrieval tool with zero annotation coverage, the description leaves meaningful gaps around access requirements, failure modes for missing or restricted secrets, and workspace scoping behavior.

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

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

Schema coverage is 50%: the workspace parameter is documented in the schema, but 'name' has no description anywhere. The phrase 'by name' confirms name is the lookup key, yet adds no detail on naming conventions, path syntax, or case sensitivity, so it only marginally compensates for the gap.

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

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

The description names a specific verb and resource ('Retrieve and decrypt a secret ... by name') and states the scope ('this account's vault'), which lets an agent distinguish it from siblings like wyrm_vault_list, wyrm_vault_put, and wyrm_vault_delete without opening their schemas. It stops short of explicitly naming those siblings or contrasting behavior.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative named; the agent must infer that this is the read path for a known secret key. The only hint is the implicit 'by name' lookup, which is not framed as usage 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 exist, so the description carries the burden, and it does disclose a security-relevant behavioral trait: names and hints only, never secret values. It does not cover auth/permission requirements, pagination, or scoping side effects beyond the parameter's own text.

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, zero filler, with the scope limitation ('NAMES ... non-secret hints') front-loaded and the negative guarantee immediately reinforcing it.

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

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

An output schema exists, so return structure needn't be described, and the description covers the one thing that matters most here: what is and isn't included in the response. Slightly incomplete in that it gives no guidance on the relationship to wyrm_vault_get or scoping behavior.

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

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

With schema description coverage at 100% for the single workspace parameter, the schema already explains its default and isolation behavior verbatim. The description adds no additional parameter meaning, so the 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?

States a specific verb ('List') and resource ('secret NAMES ... in this account's vault'), and the parenthetical clarifies it also returns non-secret hints. It implicitly separates itself from vault_get/vault_put/vault_delete by declaring what it returns, though it never names a sibling 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?

Usage is only implied: an agent can infer you call this to enumerate what secrets exist before fetching one, and the note that values are never returned hints you need a different tool for reading values. No explicit when-to-use, when-not, or named alternative (e.g. wyrm_vault_get) is given.

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 to lean on, the description carries the full burden and does so admirably: it discloses the encryption scheme (AES-256-GCM), the key model (per-account key), a critical security caveat (cloud-tier vault is Worker-decryptable, not zero-knowledge), and the destructive overwrite-on-re-put semantic. These are exactly the traits an agent needs before writing a 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 tight sentences, zero filler. The core operation is front-loaded, the security caveat is flagged with an explicit NOTE, and the overwrite warning closes it out. 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?

An output schema exists, so return values need not be described, and the remaining gaps an agent could face — encryption model, key scope, overwrite behavior, non-zero-knowledge caveat — are all covered. Nothing needed to call this tool correctly 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%, so all four parameters (name, value, hint, workspace) are already documented in the schema; the description adds only the 'keyed by name' emphasis, which aligns with the schema but contributes little beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Store an encrypted secret ... in this account's vault') plus the keying mechanism ('keyed by name'), and the enumerated examples (API key, token, credential) pin down intent. It is clearly distinguishable from vault_get, vault_list, and vault_delete 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?

Usage is implied by the 'store a secret' framing and the overwrite note tells the agent what happens on re-put, but there is no explicit when-to-use guidance, no mention of prerequisites or auth, and no routing to sibling tools such as vault_get for retrieval or vault_delete for removal.

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

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

No annotations are provided, so the description carries the full burden. It discloses that results include item counts and explains what a workspace conceptually is, but says nothing about read-only safety, pagination, ordering, or permissions. Adequate but thin for an annotation-free 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?

Two tight sentences, front-loaded with the action and scope, followed by a one-line definition of the resource. Every sentence earns its place and nothing is repeated from structured fields.

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

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

An output schema exists, so return values need no explanation, and the description does gesture at the item-count content. For a simple parameterless read tool this is largely complete; only the absence of any access/permission note keeps it from a 5.

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

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

The tool takes zero parameters, so the baseline is 4. There is no parameter behavior to clarify and the description adds nothing misleading.

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 concrete verb 'List' and resource 'workspaces', and clarifies the resource as 'project partitions' with item counts returned. An agent can tell it apart from other list-style siblings (wyrm_vault_list, wyrm_quest_list) by the account-level scope, though it never names those siblings 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?

Usage is implied by the verb and the account-wide scope, but there is no explicit statement of when to prefer this over other enumeration tools or what prerequisites exist. For a zero-parameter read tool this is forgivable but still a gap.

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