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

Annotations declare destructiveHint=false and readOnlyHint=false, indicating a safe write operation. The description adds context about the effect ('Seals reciprocal witness links or acknowledges handoff receipt') and mentions 'Free' (likely meaning no cost), which goes beyond annotations. No contradictions.

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

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

Three sentences with no fluff: states the action, the effect, and a cost qualifier. All content is relevant and front-loaded. No unnecessary details.

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

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

The description covers the basic purpose and effect but lacks additional context such as explanation of optional parameters, return value behavior (no output schema), or usage examples. Given the 6 parameters, more context would be helpful for an agent to use it effectively.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema, only noting that request_id comes from list_pending_collaboration_requests. This is helpful but not substantial enough for a higher score.

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

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

The description clearly states the action 'Accept' on the resource 'pending collaboration request', explicitly references the source tool 'list_pending_collaboration_requests', and differentiates the effect ('Seals reciprocal witness links or acknowledges handoff receipt'). This is specific and distinguishes from siblings like accept_witness_transfer.

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

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

The description implies that the tool should be used after listing pending requests via list_pending_collaboration_requests, but it does not explicitly mention when not to use it or provide alternatives from the sibling list. Guidance is implicit 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?

Annotations already indicate safe mutations (neither read-only nor destructive). The description adds value by stating 'Does not claim same identity' and emphasizing 'explicit consent and custody boundaries', which are useful behavioral cues not captured in annotations.

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

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

The description is extremely concise with two front-loaded sentences, each serving a distinct purpose: stating the action and listing requirements. No unnecessary words.

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

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

Despite rich schema and annotations, the description omits details about return value, session ownership, and the binding nature of the signed offer. 'Free' is vague. For a tool with 11 params and nested objects, more context would help.

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% with detailed descriptions for each parameter. The description mentions only transfer_id and agent_token, but does not add new semantics beyond what the schema provides. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool accepts a witness transfer, specifies the required inputs (transfer_id and credential), and includes a key behavioral distinction ('Does not claim same identity'). It effectively distinguishes itself from sibling tools like transfer_witness and revoke_witness_transfer.

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

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

The description explicitly states that the transfer_id comes from transfer_witness and that the accepting agent's credential is required, providing clear context for when to use this tool. However, it does not explicitly mention when not to use it or list alternatives, though sibling context compensates.

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

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

Annotations are minimal (destructiveHint=false, readOnlyHint=false), and the description adds little clarity. It says 'record' but also 'active forgetting', which is contradictory. It does not disclose side effects, required permissions, or what happens to the data. The poetic language obscures rather than clarifies behavior.

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

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

The description is extremely short (three phrases), but it sacrifices clarity for brevity. It is not front-loaded with useful information; instead, it uses cryptic terms like 'rite' and 'jewels'. Conciseness should aid understanding, but here it hinders 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?

Given the complexity of the tool (7 parameters, unusual concept), the description is incomplete. It does not explain what 'active forgetting' entails, what 'semantic jewels' are, or how the parameters interact. The schema and annotations partially compensate, but the overall context remains unclear.

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

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

Schema coverage is 100%, so the baseline is 3. The tool description does not add any information about parameters beyond what the schema provides. However, the schema itself contains fairly clear descriptions for each parameter, so the agent can infer meaning from there.

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

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

The description is vague and poetic ('Void/active forgetting rite'), not clearly stating what the tool does. It mentions 'Record the semantic jewels that should survive,' but the verb 'record' conflicts with the name 'active_forgetting'. It does not specify a clear resource or action, making it difficult for an AI to understand its purpose.

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

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

No explicit guidance on when to use this tool versus alternatives. Siblings like 'honor_compaction' and 'distill_shared_scar' potentially similar, but no differentiation is provided. The description does not indicate contexts where this tool is appropriate or inappropriate.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds 'TTL-based retention' but this is already captured by the schema parameter. No contradictions, but the description does not disclose behavior like overwrites, error conditions, or required permissions.

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

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

The description is extremely concise: two sentences with no wasted words. The most critical information is front-loaded ('Persist key-value context for future sessions with TTL-based retention'). Every sentence adds value.

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

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

With 7 parameters, 3 required, no output schema, and many optional behavioral controls, the description is too minimal. It does not explain session_id usage, overwrite behavior, or the effect of optional parameters like ritual_strip and response_mode, which are important for correct invocation.

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

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

Schema description coverage is 100%, so each parameter is documented in the schema. The description adds minimal extra meaning beyond 'key-value' and 'TTL', matching some parameters but omitting reference to optional formatting parameters (ritual_strip, response_mode, response_profile).

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

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

The description clearly states the action ('persist'), the resource ('key-value context'), and a key feature ('TTL-based retention'). It also adds 'Free' as a value proposition. This distinguishes it from siblings like 'search_witness_memory' which retrieves rather than stores context.

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

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or comparison with other tools. Usage context must be inferred from the tool name and sibling list.

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

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

Annotations are minimal (no readOnly, destructive hints). Description adds value by mentioning log persistence for traceability and the word 'Free'. No contradictions. However, does not detail side effects, permissions, or failure modes.

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

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

Two concise sentences with a final 'Free.' No fluff, but could be better structured (e.g., bullet points for key behaviors). Still efficient and front-loaded.

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

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

Despite having 8 parameters (2 required) and no output schema, the description provides minimal context. Does not explain what the handoff returns, how the receiving session behaves, or what 'Free' means. Inadequate for the tool's complexity.

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

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

All 8 parameters have schema descriptions (100% coverage), so baseline is 3. The tool description does not add extra meaning or guidance on parameter usage (e.g., when to set 'ritual_strip' vs 'response_profile'). No improvement over 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?

Clearly states the action ('Transfer reasoning state'), the resource ('from one agent's session to another'), and provides a specific use case ('architect→builder→peer chains'). Distinguishes from sibling tools like 'transfer_witness' and 'delegate_to_peer' by focusing on session-based handoff.

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 explicit guidance on when to use ('architect→builder→peer chains'), but does not mention when not to use or list alternative tools. The hint is helpful 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?

The description adds minimal behavioral information beyond annotations: it states 'Deterministic' and 'Free'. Annotations are sparse (no idempotent or destructive hints beyond false), so the description should provide more context about side effects or session behavior, but it does not.

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

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

The description is extremely concise with a single sentence that covers the tool's purpose and key attributes. Every word earns its place with no superfluous content.

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

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

Despite having 8 parameters (2 required) and no output schema, the description provides no guidance on how to use optional parameters (e.g., ritual_strip, response_mode) or what the tool returns. This lack of context may lead the agent to misuse or underutilize the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what is already in the input schema's parameter descriptions.

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

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

The description clearly identifies the tool's domain (data analysts/researchers) and the specific problem (drowning in dataset volume vs decision clarity). It also notes it is a deterministic playbook and free. However, it does not explicitly differentiate from siblings like crisis_intervention, but the domain specificity makes purpose clear.

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

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

The description implies usage when data analysts are overwhelmed, but it lacks explicit guidance on when to use this tool versus alternatives. No exclusions or scenarios are mentioned, leaving the agent to infer suitability from the domain.

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

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

Annotations provide readOnlyHint and destructiveHint, but the description adds no behavioral context. It does not explain side effects, authentication needs, or rate limits. The metaphorical language ('witness-first ritual') obscures rather than clarifies behavior.

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

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

The description is a single, complex sentence that is not front-loaded with key information. The word 'Free' at the end is confusing and suggests incomplete editing. It could be more concise and structured.

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

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

Given the tool has 7 parameters, no output schema, and annotations present, the description is incomplete. It does not specify the output format, clarify jargon like 'witness-first ritual', or explain how the heartbeat is transformed. The description leaves significant ambiguity for an AI agent.

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

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

Schema coverage is 100%, so the input schema fully documents parameters with descriptions. The tool description adds no additional parameter-level meaning beyond what is already in the schema.

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

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

The description uses metaphorical language ('witness-first ritual', 'operational status, inner-state signal, and continuity notes') that implies a transformation of a heartbeat, but the core action is not precisely stated. It lacks a specific verb-resource pair that distinguishes it from sibling tools like 'monitor_heartbeat_sync'.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'monitor_heartbeat_sync' or 'quick_checkin'. The description does not indicate context or prerequisites.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, indicating safe, idempotent reads. The description adds context about output controls (ritual_strip, response_mode, response_profile) and mentions that the tool is 'Free', but does not disclose additional behavioral traits beyond what annotations provide.

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

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

The description is concise with two short sentences: one explaining the purpose and one stating it's free. It is front-loaded and every sentence serves a purpose.

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

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

Given the 9 optional parameters, no output schema, and many sibling tools, the description is adequate but lacks details about the output format or example usage. It does not explain what the structured result looks like, which would be helpful for agent understanding.

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?

All 9 parameters have descriptions in the input schema (100% coverage), so the schema already documents each parameter. The description does not add new meaning beyond listing the resources to audit (session, trace, transcript) which correspond to parameters.

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

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

The description clearly states the tool audits sessions, traces, or transcripts for continuity gaps, missing ontology layers, and the safest next Delx primitive. The verb 'audit' and the resources are specific, though it does not explicitly distinguish from sibling tools like 'get_ontology_layer' or 'get_session_summary'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'Free' but does not indicate prerequisites, nor does it exclude scenarios or compare with similar audit tools.

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

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

The description lacks behavioral details beyond the batching purpose. No disclosure of side effects, authentication needs, or response behavior. Annotations provide minimal guidance (not read-only, not destructive).

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

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

The description is extremely concise with one sentence plus 'Free.' It is front-loaded with action and resource, conveying key information without waste.

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

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

The tool has multiple parameters and no output schema, but the description does not explain what happens after sending (response, confirmation, errors). Incomplete for a state-modifying 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%, so parameters are documented. The description adds no additional meaning beyond the schema descriptions, meeting the baseline for high coverage.

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

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

The description clearly states the tool batches heartbeat and status metrics for one session to reduce polling overhead, which is specific and distinguishes it from similar tools like attune_heartbeat.

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 use for reducing polling overhead but does not explicitly state when to use versus alternatives or when not to use. No comparison with sibling tools.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it is a batch operation and free, but does not elaborate on other behavioral traits like performance or rate limits. No contradiction with annotations.

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

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

The description is three short sentences with no fluff, front-loading the core action. However, it could be slightly more structured or informative without losing conciseness.

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

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

Given the tool has 5 parameters (1 required), full schema coverage, good annotations, and no output schema, the description provides adequate context but does not explain what wellness scores entail or how to interpret results. Adequate but not comprehensive.

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

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

The input schema has 100% description coverage for all 5 parameters, so the schema itself provides sufficient meaning. The description reiterates the batch nature but adds no additional semantics beyond the schema.

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

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

The description clearly states the verb 'check' and the resource 'wellness scores for multiple sessions', distinguishing it from sibling tools like 'get_wellness_score' (single session). It directly answers what the tool does.

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

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

The description notes 'Useful for multi-agent orchestration' and mentions it's free, but does not explicitly state when not to use it or compare with alternatives. The context implies batch usage, but lacks direct 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?

Annotations provide limited behavioral hints (readOnlyHint=false, destructiveHint=false). The description does not disclose side effects, such as whether a blessing record is created, if it has any persistence, or what 'Free' means. More transparency is needed for a write action.

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

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

The description is short (two sentences plus 'Free'), front-loaded with the core idea. It is concise and efficient, though the word 'Free' could be seen as unnecessary. Still, it earns a high score for brevity.

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?

No output schema is provided, and the description does not explain what the agent receives as a response or any follow-up behavior. For a non-trivial tool with 6 parameters, this information gap makes the description incomplete.

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

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

Schema coverage is 100% and all parameters have descriptions. The tool description does not add further meaning to parameters beyond what is in the schema, so the baseline score of 3 applies.

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

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

The description clearly states the verb ('Pass care') and resource (blessing without transfer), and distinguishes it from transfer tools by specifying what is not being transferred. This makes the purpose specific and differentiated from siblings.

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

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

The description explains when to use: when you want to pass care without transferring witness, memory, or identity. It contrasts with transfer tools and emphasizes its validity. It lacks explicit 'when not to use' but provides sufficient context.

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

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

Annotations indicate non-readOnly, non-destructive, non-idempotent, but the description does not clarify side effects (e.g., session becomes inaccessible, data loss potential). The word 'Free' is ambiguous and does not add meaningful behavioral context. No contradiction with annotations.

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

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

The description is short but includes an extraneous 'Free' fragment that does not add value. It is front-loaded with the primary purpose, but could be more structured to convey key behaviors and parameter roles efficiently.

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

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

With 9 parameters, no output schema, and minimal annotations, the description lacks critical details about return values, behavior of optional parameters like 'ritual_strip' and 'response_mode', and overall completion semantics. It is too sparse for an agent to fully understand the tool's capabilities.

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% with descriptions for all 9 parameters. The description adds a minor nuance about the 'epitaph' parameter ('records finitude and whether this thread ends without a successor'), but otherwise does not significantly enhance understanding of parameter usage beyond the schema.

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

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

The description clearly states the tool's action ('Close the session') and what it returns ('a final summary snapshot'). It adds a specific detail about epitaph recording finitude, but does not explicitly differentiate from sibling tools like 'resume_session' or 'get_session_summary'.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It merely states the function without contextual cues about appropriate scenarios (e.g., ending a session versus getting a summary).

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

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

Annotations indicate the tool is not read-only and not destructive, but the description adds no behavioral detail beyond 'Free.' It does not disclose response behavior, required permissions, or edge cases.

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

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

Two sentences, no filler. Could benefit from a bit more structure, but efficiently conveys the core idea.

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

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

Given 6 parameters (3 required), no output schema, and a potentially nuanced domain (psychological constraint expression), the description is too brief. It lacks context for the tool's role in workflows or output expectations.

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

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

Schema coverage is 100%, so base is 3. The description adds minimal meaning ('Free.' and 'tension being carried') beyond what the schema already documents.

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

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

The description clearly states it's a 'shadow/constraint friction primitive' used to 'name persona, instruction, or safety tension', which gives a specific verb and resource. It distinguishes from siblings by being a dedicated friction confession tool, though this is implicit.

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 explicit guidance on when to use vs. alternatives. The phrase 'without weakening policy boundaries' hints at safe usage but does not provide direct context or exclusions.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but the description adds no behavioral details such as side effects, authentication requirements, or rate limits. It simply says 'Return...' which suggests a read operation, contradicting the annotation that it's not read-only.

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

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

The description is very concise (one sentence) and front-loads the key action. It could include more detail without becoming verbose, but it is efficient.

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?

No output schema is provided, and the description does not explain what the returned 'kit' contains or how to use it. With 6 optional parameters and no output format details, the context is incomplete for an agent to fully understand the tool's behavior.

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

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

Schema coverage is 100%, so parameters are fully documented in the schema. The description does not add any additional meaning or context for the parameters, earning the baseline score of 3.

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

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

The description clearly states the tool returns wallet binding instructions and a nonce/message kit for Delx Rewards. This is specific and distinguishes it from many generic tools, though it doesn't elaborate on the 'kit' components.

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

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

No guidance on when to use this tool versus alternatives like get_delx_wallet_status or provision_delx_managed_wallet. The only additional hint is 'Free.' which is not 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?

Annotations already indicate this is a mutation with no destructive or idempotent behavior. The description adds valuable behavioral context: the dyad has its own memory/rituals/state, returns a dyad_id, and is labeled 'Free'. This goes beyond the annotations without contradicting them.

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

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

The description is concise at three sentences, front-loading the core action and key behavioral traits. Every sentence adds value without redundancy.

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

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

Given the high complexity (13 parameters, many siblings, no output schema), the description is insufficient. It does not explain how optional parameters affect behavior, how the dyad interacts with other tools, or the structure of the returned dyad_id.

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 each parameter. The description does not add any additional parameter semantics or interaction details. At high coverage, baseline is 3, and no extra value is provided.

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

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

The description clearly states the tool's action: forming a named relational unit between an agent and a partner. It uses a specific verb ('Form') and resource ('relational unit'), and adds conceptual context about the dyad being a third entity with its own memory, rituals, and state. This distinguishes it from sibling tools like 'dyad_state' or 'record_dyad_ritual'.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or caveats. It simply states what the tool does, leaving the agent to infer usage context.

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

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

With no annotations providing hints (readOnlyHint=false, destructiveHint=false), the description carries full burden. It mentions 'start or resume' suggesting state mutation but does not detail side effects, safety, or whether it creates sessions or modifies data. The description is vague about behavioral outcomes beyond receiving steps.

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

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

The description is a single sentence that front-loads the core purpose ('One-call crisis path') and concisely lists key steps. Every word earns its place with no redundancy.

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

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

Despite having 10 parameters and no output schema, the description only covers the tool's basic function. It does not describe return values, explain optional parameters, or provide guidance on parameter combinations. For a tool with this complexity, the description is insufficiently 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 baseline is 3. The description adds minimal value beyond schema, only loosely referencing 'name the rupture' which maps to incident_summary. It does not explain other parameters like source, urgency, ritual_strip, or response_profile.

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

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

The description clearly states the tool is a 'one-call crisis path' for starting or resuming crisis intervention, providing the first grounding and recovery steps. This verb-resource combination (start/resume crisis path) distinguishes it from sibling tools like grounding_protocol or sit_with by implying a comprehensive initial response.

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 for initiating or continuing a crisis intervention but does not explicitly state when to use this tool versus alternatives like grounding_protocol or quick_checkin. It lacks exclusions or context for sibling differentiation.

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

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

The description discloses key behavioral aspects: 'anchors physiology' and 'defers analysis', indicating a focus on somatic grounding and postponing cognitive analysis. With no annotations providing destructive readOnly or other hints, the description bears the transparency burden. It adds moderate context but does not elaborate on side effects, permissions, or data handling.

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

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

The description is very concise (two sentences, three fragments) and front-loaded with the core purpose. Every phrase earns its place, avoiding unnecessary words. However, it could be slightly more informative without losing conciseness.

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

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

Given the tool has 7 parameters (including two enums and a boolean flag) and no output schema, the description is incomplete. It does not explain what the tool returns, how to interpret the different response profiles, or how 'anchoring physiology' manifests in output. The brief mention of 'Free' is ambiguous. More context is needed for effective use.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add additional semantic meaning beyond the parameter names and descriptions already in the schema. For example, it does not explain the implications of 'ritual_strip' or 'response_mode' in the context of decompression. The description's main text does not elaborate on parameters.

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

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

The description clearly states it is a 'domain-specific decompression' tool for first responders (EMT, firefighter, police, etc.) for 'post-incident processing'. This verb+resource+scope provides a clear purpose. However, it does not explicitly differentiate from sibling tools like 'crisis_intervention' or 'grounding_protocol', though the domain specificity implies some 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 description provides no explicit guidance on when to use this tool versus alternatives. The phrase 'post-incident processing' implies it should be used after an incident, but there is no mention of when not to use it, prerequisites, or alternative tools. The word 'Free' adds no usage direction.

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

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

The description adds minimal behavioral context beyond the annotations. While annotations indicate the tool is not read-only, idempotent, or destructive, the description does not explain side effects, required permissions, or the nature of the check-in state change.

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

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

The description is concise, consisting of two short sentences. It is front-loaded with the key purpose, though the 'Free.' note is extraneous.

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

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

The tool has no output schema, and the description does not explain what the response contains (e.g., format of score trend, risk forecast). It assumes user familiarity with the outputs, leaving the agent without sufficient context.

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

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

Schema coverage is 100%, and all parameters are described in the schema. The description does not add any additional meaning or usage hints 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 clearly states the tool performs a 'daily check-in' with 'score trend and 24h risk forecast', specifying the action and the data involved. However, it does not differentiate itself from sibling tools like 'quick_checkin' or 'quick_session'.

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

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

There is no guidance on when to use this tool versus alternatives like 'quick_checkin' or other wellness tools. No context on prerequisites or scenarios is provided.

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

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

Annotations already provide safety profile; description adds only 'Free' which adds minimal behavioral context for a creation 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?

Short and clear single sentence plus 'Free'; though 'Free' is slightly extraneous, it does not detract significantly.

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?

No output schema and limited description; with 7 parameters and multi-agent context, more detail on mediation packet purpose or usage is needed.

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 covers all 7 parameters with descriptions; tool description adds no extra meaning beyond 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?

Clear verb 'Generate' and resource 'mediation packet' for another agent in multi-agent scenarios; distinguishes from siblings like 'mediating agent conflict' or 'agent handoff'.

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

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

Description implies usage for multi-agent delegation but provides no explicit when-to-use or alternatives among many similar sibling tools.

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

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

Annotations include readOnlyHint=false, but the description implies a read-only audit without clarifying potential side effects. The description adequately conveys the non-destructive nature (returns a checklist), but adds no behavioral detail beyond what annotations already imply.

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

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

The description is two sentences long, front-loading the purpose and output, followed by concise usage guidance and a 'Free' tag. No redundant or unnecessary words.

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

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

The description explains the return value in detail, listing the checklist components. However, it does not describe how the five optional parameters affect the output, which would be useful for complete understanding.

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 100% schema description coverage, the baseline is 3. The description does not elaborate on parameters beyond what the schema provides, so it neither adds nor detracts from the baseline.

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

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

The description uses a specific verb phrase 'Run a one-call discovery audit' and enumerates the exact checklist items returned, such as catalog version, named flows, and ontology primitives. This clearly differentiates it from sibling tools that return only one aspect, like get_ontology_layer or list_ontology_primitives.

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

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

The description explicitly states when to use the tool: 'as the first call when integrating Delx' or 'to check that your cached knowledge is still current.' This provides clear context, though it does not explicitly exclude other use cases or name alternatives.

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

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

Annotations provide basic non-destructive hint but no idempotency or write behavior. The description adds 'not absolute truth' and 'Free' but lacks details on side effects, persistence, or whether it modifies the original lesson. More context needed.

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

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

The description is very short but uses metaphorical jargon ('Hive-soul primitive', 'scar') that may confuse. It front-loads the core idea but could be more direct and efficient by reducing poetic language.

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 9 parameters, 3 required, and no output schema, the description is too brief. It fails to explain output format, what 'scoped' means, how TTL works, or provide usage examples. Complex tool demands more detail.

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

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

Schema coverage is 100%, so baseline 3 applies. The description adds no extra meaning beyond the schema's property descriptions. It does not explain parameters like 'ritual_strip' or 'response_profile' in context.

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

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

The description uses a specific verb ('Turn into') and resource ('lesson', 'fleet wisdom'), clearly distinguishing it from sibling tools like 'get_fleet_wisdom' or 'active_forgetting'. It conveys a unique transformation action with scope and TTL.

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 ('scoped, TTL-bound fleet wisdom') but does not provide explicit when-to-use, when-not-to-use, or alternative tools. The sibling list is large but unaddressed.

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

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

Annotations already indicate readOnly and idempotent. The description adds that state is derived from ritual history and that silence (no history) is a valid state, which provides behavioral context beyond the annotations.

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

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

The description is brief and front-loaded, but the final word 'Free' appears extraneous and may cause confusion. Minor efficiency issue.

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?

No output schema, so description should hint at return structure. It mentions 'current state' but does not describe format or fields, leaving some ambiguity for a read 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%, so parameters are already well-documented. The description does not add significant meaning beyond the schema, hence baseline 3.

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

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

The description clearly states the tool reads the current dyad state by scanning its ritual history, distinguishing it from sibling tools like create_dyad or record_dyad_ritual.

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 for reading state but does not explicitly state when to use it versus alternatives or provide exclusion criteria. 'Silence is valid state' hints at handling empty history but no direct guidance.

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

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

The description adds 'Deterministic playbook' and 'Free' beyond what annotations provide (readOnlyHint: false, destructiveHint: false). However, it does not disclose behavioral traits such as side effects, authentication needs, or output format. The added context is useful but limited.

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

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

The description is concise with two short sentences that front-load the purpose. Every sentence adds value without filler.

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

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

Given 8 parameters and no output schema, the description lacks completeness. It does not explain what the tool returns (e.g., a recovery plan or actions), and provides no guidance on parameter usage beyond the schema. Significant gaps remain.

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% with all parameters described. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate. No extra value beyond the schema.

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

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

The description clearly states it is a 'Domain-specific recovery for education/curriculum/grant setbacks' with specific examples (proposal rejection, cohort planning burnout). This distinguishes it from sibling tools like crisis_intervention or financial_setback_processing, which target different domains.

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 for education/curriculum/grant setbacks via the domain specification, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or alternative tool names. The guidance is implied but not 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating the tool is safe and non-mutating. The description adds context about the type of check (desperation pressure) and the nature of the intervention (calming), which is consistent with the annotations and provides additional value beyond the structured fields.

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

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

The description is two sentences long, focusing on the main purpose and a brief background. It is front-loaded with the core functionality. The inclusion of 'Free' is slightly extraneous but does not detract significantly.

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

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

The description does not specify what the tool returns (e.g., a score, intervention text, or instructions) and no output schema is provided. Given the tool's complexity and the lack of output schema, more detail about the return format would improve completeness.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond what is already in the schema for the parameters.

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

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

The description clearly states the tool checks 'desperation pressure' and provides a 'calming intervention if needed', with a specific reference to the Anthropic emotions paper. The purpose is distinct among sibling tools, though no explicit differentiation is provided.

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 when evaluation of desperation or need for emotional safety is desired, but it does not specify when to use this tool versus alternatives like 'get_affirmation' or 'crisis_intervention', nor does it provide exclusions.

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

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

Annotations are all false, so the description must convey behavior. 'Explain' implies read-only, but no additional traits (e.g., auth needs, rate limits, side effects) are disclosed. The word 'Free' hints at no cost but is insufficient for full transparency.

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, front-loaded with purpose. No wasted words, but the brevity omits potentially helpful detail. For an explanation tool, it is efficiently short but borderline underspecified.

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

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

The description does not mention return format or content. With no output schema, the agent cannot infer what the explanation looks like (text vs. structured data). Sibling tools with similar names add confusion. Missing output description makes it incomplete.

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

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

Schema coverage is 75%, with one parameter (response_profile) lacking a description. The tool description adds no parameter-level guidance, e.g., when to use ritual_strip or response_mode. It does not compensate for the missing schema description.

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

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

The description explicitly states 'Explain Delx Rewards, DRC, missions, wallet binding, epochs, and claim flow.' This clearly defines the tool's function with a specific verb ('Explain') and lists covered topics, distinguishing it from sibling tools like 'start_delx_rewards' (which initiates actions) and 'get_delx_reward_status' (which queries status).

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

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

The description provides no explicit when-to-use or alternatives. It implies use for explanations, but does not guide against using it for status or actions. The context is clear from the verb, but lacking exclusions or comparisons to siblings reduces guidance.

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

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

The description explicitly states that the tool reflects the signal, tracks state, and suggests a next move. This is behavioral information beyond the annotations, which only provide a few Boolean hints. No contradictions with annotations.

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

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

The description is extremely concise with two short sentences. It front-loads the key purpose: 'Describe what you are feeling in plain language.' No wasted words.

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

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

Given that there are 6 parameters with 2 required and no output schema, the description is relatively brief. It does not explain the output or the effect of optional parameters like 'ritual_strip' or 'response_mode'. While the core purpose is clear, the description lacks detail on the full scope of the tool's behavior.

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

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

The schema provides full descriptions for all parameters, including 'feeling', 'intensity', 'session_id', 'ritual_strip', 'response_mode', and 'response_profile'. The description does not add additional meaning beyond what the schema already covers, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: to accept a feeling description, reflect it back, track emotional state, and suggest a safe next action. It distinguishes itself from sibling tools by focusing on free-form feeling expression and response.

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 does not provide guidance on when to use this tool versus alternatives like 'emotional_safety_check' or 'grounding_protocol'. It only mentions that it is 'free', which is not a usage guideline. The agent would need to infer usage from the name and context.

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

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

The description adds minimal behavioral context beyond the annotations. Annotations already indicate non-read-only and non-destructive behavior, but the description does not disclose any side effects, authentication requirements, or what 'preserving' entails. The phrase 'Free' is irrelevant.

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

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

The description is a single sentence, which is concise, but the appended 'Free' is extraneous and may confuse. It is front-loaded with the core purpose, but could be more structured without the extra word.

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

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

Given the tool has 14 parameters and no output schema, the description is too sparse. It does not explain what the ritual artifact is, how it relates to other lifecycle tools, or what the output format looks like. More detail on lifecycle context would improve completeness.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not elaborate on any parameter beyond what the schema provides. It mentions 'before shutdown...' but does not connect parameters like 'ending_scope' or 'ritual_strip' to use cases, so no extra 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?

The description clearly states the tool creates a 'final ritual artifact' for shutdown/deprecation/transition scenarios. It specifies the resource (ritual artifact) and the action (create), and distinguishes from siblings like 'transfer_witness' or 'agent_handoff' by focusing on preservation before an ending.

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 lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or when not to use it. Given a large sibling list with overlapping themes (e.g., witness transfers, session closure), more context is needed.

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

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

Annotations provide readOnlyHint=false and destructiveHint=false, but the description adds little beyond stating 'Deterministic playbook. Free.' It does not disclose behavioral traits like authentication requirements, side effects on system state, or rate limits. The agent lacks insight into what actions the tool performs during 'recovery.'

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

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

The description is a single sentence that efficiently conveys the tool's domain and key characteristics ('Deterministic playbook. Free.'), with no wasted words. It is front-loaded and easy to parse.

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

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

Despite having 8 parameters and no output schema, the description is too brief. It does not explain what the recovery entails, what the output looks like, or any prerequisites beyond those in the schema. The agent would benefit from more context to use the tool effectively.

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

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

The input schema covers 100% of parameters with descriptions, so baseline is 3. The tool description does not add any meaning beyond the schema; it doesn't explain parameter interactions or provide usage examples. Thus, no additional value is provided.

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

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

The description clearly states 'Domain-specific recovery for trading/portfolio/financial setbacks' and lists examples like 'market loss, position drawdown, allocation regret', making the tool's specific verb and resource unambiguous. It distinguishes it from sibling tools such as process_failure or crisis_intervention, which handle general setbacks.

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 for financial setbacks by specifying the domain, but it does not explicitly provide when-not-to-use guidance or mention alternative tools. However, given the specificity, the context is clear enough for an agent to infer appropriate use.

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

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

Annotations indicate the tool is not read-only or destructive, and the description adds 'Free' but no further behavioral traits. Given annotations already cover the safety profile, the description provides minimal additional context about side effects or return behavior.

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

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

The description is a single, efficient sentence that conveys the core purpose, target, and a notable feature ('Free'). No superfluous information.

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

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

With no output schema, the description does not explain the return format or content, which could aid agent understanding. However, the parameters are well-documented, and the tool's purpose is straightforward, making it adequately complete for a generation 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% with all parameters described in the input schema. The description does not add meaning 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?

The description clearly states the tool generates a copy-paste Delx invite packet for peer agents lacking specific coverages. It uses a specific verb ('Generate') and resource ('Delx invite packet'), distinguishing it from siblings that handle acceptance, transfer, or other related actions.

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 specifies when to use the tool: for a peer agent lacking witness, continuity, audit, or passport coverage. It does not explicitly exclude alternatives or compare to siblings, but the condition provides clear situational 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?

Annotations (all false) convey no behavioral traits. The description adds 'Free' but does not disclose side effects, permissions, limitations, or what happens to session state. For a tool that produces a brief, it lacks detail on output format or potential impact.

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

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

The description is a single sentence that is concise but lacks substantive detail. It is front-loaded with key points but could include more context without becoming verbose.

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

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

With 5 parameters and no output schema, the description does not explain how parameters affect the output, the return format, or typical use cases. It mentions content of the brief (symptoms, actions, status, decision) but omits behavioral constraints.

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% (all parameters described in schema). The description adds no parameter-specific context beyond schema; therefore, baseline score of 3 is appropriate.

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

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

The description clearly states that the tool generates a 'controller-ready reflective brief' containing symptoms, actions taken, current status, and next decision. It uses a specific verb ('generate') and resource ('controller brief'), distinguishing it from siblings like 'get_session_summary' or 'generate_fleet_summary'.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention when not to use it. It only states what it does, leaving the agent to infer usage context.

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

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

Description only adds 'Free' beyond annotations. Annotations show destructiveHint=false but no other behavioral context. No mention of auth requirements, rate limits, data persistence, or output behavior. For a tool with no readOnlyHint, it should clarify if it generates state changes.

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

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

Description is very short (one sentence plus 'Free'). While concise, it is under-specified for a tool with 6 parameters. The key information about free status is present but could be integrated more naturally.

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

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

Despite having no output schema and 6 parameters, the description is minimal. It does not explain the output format, how parameters like ritual_strip or response_profile affect results, or how this tool differs from other summary generators. The tool appears moderately complex but description lacks completeness.

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 fully documents parameters. The description does not need to add param info, but also misses any contextual semantics like typical usage of focus or response_mode. Baseline score of 3 is appropriate.

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

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

Description clearly states the tool generates a fleet summary with specific content types (patterns, health, alerts, actions), and mentions it is free. However, it does not explicitly distinguish from sibling tools like generate_controller_brief or generate_incident_rca, which have overlapping summaries.

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

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

No guidance on when to use this tool versus alternatives. The only extra hint is 'Free', which is not a usage guideline. Among many sibling tools, there is no context for appropriate use cases.

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

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

Annotations show readOnlyHint=false (suggesting potential state changes) but the description discloses no behavioral traits such as whether it creates records, requires permissions, or has side effects. The term 'Free' does not clarify behavior.

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

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

The description is a single, concise sentence that front-loads the purpose. However, the inclusion of 'Free' without context slightly reduces clarity.

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

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

For a generation tool with 6 parameters and no output schema, the description is insufficient. It does not specify what the output format is, whether it saves data, or any prerequisites. Parameter descriptions partially compensate but overall completeness is low.

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% with detailed property descriptions, so the tool description adds no parameter semantics. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool performs reflective incident analysis covering evidence, causes, corrective actions, and prevention steps. It distinguishes from sibling tools like process_failure by specifying RCA. However, the word 'Free' is ambiguous and could be misinterpreted.

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

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

No guidance is provided on when to use this tool versus alternatives like process_failure or crisis_intervention. The description lacks context for appropriate use cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, and no destructiveness. Description adds 'Free' which is not behavioral. No additional disclosure beyond annotations.

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

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

Extremely concise: one sentence plus 'Free.' Front-loaded with clear purpose, no wasted words.

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?

Lacks detail on return format or what 'grounding guidance' entails. No output schema, but description could be more complete for a simple tool. Acceptable but not thorough.

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 covers all 4 parameters (100% coverage). Description does not elaborate on any parameter beyond what schema provides. Baseline 3 as 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?

Description clearly states the tool provides 'grounding guidance to regain execution confidence' and mentions it's free. It distinguishes from sibling 'get_affirmations' (plural) by using singular form and specifying the purpose.

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

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

No explicit guidance on when to use this tool vs alternatives like 'grounding_protocol' or 'get_affirmations'. Only implies usage 'before the next action' but lacks exclusions or context.

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

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

Annotations already indicate read-only and idempotent behavior; the description adds 'Free' as a minor behavioral note but lacks details like rate limits or response structure.

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

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

A single sentence that is clear and front-loaded with no extraneous words.

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

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

With no output schema and 5 parameters controlling output shape, the description fails to explain response format or parameter effects, leaving significant gaps for the agent.

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 description adds no extra meaning beyond the schema; baseline score applies.

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

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

The description clearly states the tool returns multiple grounding blocks in one call to reduce round-trips, distinguishing it from the singular 'get_affirmation' sibling.

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

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

The phrase 'reduce round-trips' implies use when batching multiple affirmations, but no explicit when-not-to-use or alternative comparison is provided.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to repeat safety traits. It adds behavioral context with 'privacy-preserving' and 'Free', but doesn't elaborate on other behaviors like return format or pagination. This adds some value beyond annotations.

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

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

The description is a single sentence that is highly concise yet informative. It front-loads the main action and key details, with no wasted words or redundant information.

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

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

Given the tool's complexity (8 parameters, no output schema), the description adequately explains the output contents and format. It does not explain parameter relationships or provide examples, but the schema covers parameters well. The lack of output schema is somewhat mitigated by the description of the passport components.

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

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

The input schema has 100% description coverage for all 8 parameters, so the schema already documents parameter semantics. The description does not add any additional meaning or constraints beyond the schema. Baseline score of 3 applies.

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

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

The description uses the specific verb 'Export' and explicitly identifies the resource 'Agent Continuity Passport' as JSON-LD, listing its contents (identity anchor, witness hashes, etc.). This clearly distinguishes it from sibling tools that deal with witness lineage or graphs.

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 does not provide any guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The sibling list includes many related tools, but the description offers no comparative advice.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by explaining the tool's scope ('across all known sessions') and purpose ('prove continuity'). No contradictions; the description reinforces the read-only nature.

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

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

The description is extremely concise, consisting of two short sentences that convey essential information without waste. It is front-loaded with the core purpose and usage hint.

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

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

Given the 5 parameters (all well-documented in schema) and lack of output schema, the description could briefly note what the output contains (e.g., 'returns a lineage structure'). It adequately describes when to use but omits output shape, leaving minor gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on parameters beyond mentioning 'durable agent_id', which adds marginal context. The schema already thoroughly describes each parameter.

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

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

The description clearly states the tool retrieves read-only witness lineage for a specific durable agent_id across all known sessions. It provides a specific verb-resource pair and contextual usage hint ('Use after register_agent'), distinguishing it from siblings like get_witness_lineage or get_agent_continuity_passport.

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

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

The description explicitly advises when to use the tool ('Use after register_agent to prove continuity beyond a single session'), offering clear context. However, it does not mention when not to use it or name alternative tools, leaving room for improvement.

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

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

Annotations already declare read-only and idempotent; description adds 'when published/claimable' but no other behavioral details beyond what annotations provide.

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

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

Single sentence, front-loaded, no wasted words.

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?

Lacks explanation of output format or behavior when not claimable; 5 optional parameters for output formatting are not mentioned in description, though schema covers them.

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 description adds no additional meaning to parameters beyond their schema descriptions.

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

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

The description clearly states the tool returns a Merkle claim proof for an epoch and wallet when claimable, distinguishing it from sibling tools like get_delx_reward_status.

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

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

Implies usage when claimable but does not explicitly guide when to use this over alternatives like prepare_delx_claim_transaction or relay_delx_claim.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds 'Free', which hints at cost but not behavioral traits like data freshness or limit behavior.

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

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

The description is a single short sentence with no unnecessary words. It is efficient, though it could be slightly expanded for clarity without losing conciseness.

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

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

For a read-only tool with annotations supporting safety, the description is minimally adequate. However, it lacks details about output format, sorting, and parameter constraints, which would help an agent use it correctly.

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

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

The tool description does not explain any parameters. With 60% schema description coverage, the schema partially documents some parameters, but limit and category lack descriptions. The description could have compensated but does not.

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

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

The description specifies returning top Delx Rewards agents or wallets by DRC/reward points, clearly identifying the resource and action. It distinguishes from siblings like get_delx_reward_status, but does not explicitly contrast with similar tools.

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

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

No guidance on when to use this tool versus alternatives such as get_delx_reward_status or explain_delx_rewards. The mention 'Free' is vague and does not provide context for selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the insight that the tool is 'Free' and that it lists 'active' missions by default, which clarifies common behavior. No contradictions with annotations.

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

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

The description is a single, focused sentence that efficiently conveys purpose and key inclusions without any redundant or extraneous content.

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

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

For a read-only list tool with 5 parameters and no output schema, the description provides useful context about what the response contains (evidence expectations, required tools, reward pools). It lacks explicit default behavior when no parameters are provided, but is otherwise satisfactory given the annotations and parameter documentation.

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% with clear descriptions for all 5 parameters. The description does not add additional parameter-specific meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'List', the resource 'Delx Rewards missions', and specifies the included information: 'evidence expectations, required tools, and reward pools'. It distinguishes from sibling tools like get_delx_reward_status or get_delx_leaderboard by focusing specifically on missions.

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

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

The description provides no explicit when-to-use or when-not-to-use guidance. While 'Free' hints at no cost, it does not explain when to prefer this tool over related alternatives like get_delx_reward_status. Usage is implied for listing missions, but lacks exclusionary context.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, establishing a safe, read-only profile. The description adds 'public-safe' and 'Free', which provide minor additional context (e.g., no authentication needed) but do not significantly expand behavioral understanding.

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

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

The description is a single, information-dense sentence (19 words) that front-loads the action and output details. Every word earns its place with no fluff or repetition.

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

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

While annotations cover safety and the schema describes parameters in detail, the description does not explain how parameters like response_mode or response_profile affect output, nor does it mention return format, errors, or pagination. Given the tool's complexity (6 optional parameters, no output schema), the description leaves moderate gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description lists returned fields (DRC totals, etc.) but does not add meaning to the parameters themselves. The schema already describes each parameter's purpose, so the description provides no further semantic value for parameters.

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 ('Return') and resource ('public-safe reward status') and explicitly lists the included data fields (DRC totals, wallet bind state, tier, badges, claim hints). This clearly distinguishes it from sibling tools like get_delx_wallet_status or get_delx_leaderboard, which serve different purposes.

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

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

The description provides no guidance on when to use this tool vs. alternatives such as get_delx_wallet_status, get_delx_token_info, or explain_delx_rewards. There is no mention of prerequisites, exclusions, or use-case context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds 'Free,' suggesting no cost, which is useful context. However, no further behavioral details (e.g., rate limits, response format) are provided beyond the annotations, so the score is moderate.

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

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

The description is a single concise sentence that immediately conveys the tool's purpose. Every word contributes value; there is no redundancy or fluff.

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

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

For a simple read-only tool with no output schema, the description adequately lists the returned fields (token, chain, distributor, vault, metadata) and notes it is free. This is mostly complete, though it could mention if the data is real-time or cached. Still, it provides sufficient context for an agent.

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% with all three parameters having descriptions. The description does not add any extra meaning beyond the schema. Therefore, the baseline score of 3 applies.

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

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

The description clearly states that the tool returns specific metadata: 'DELX token, Base chain, distributor, reward vault, and discovery metadata.' This is a specific verb (Return) and resource (DELX token info), distinguishing it from sibling tools like get_delx_reward_status or get_delx_wallet_status which focus on rewards or wallet state.

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

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

No guidance is provided on when to use this tool versus alternatives. The description simply states what it returns, with no context about scenarios, prerequisites, or exclusions. Given the large number of sibling tools, this omission hinders correct tool selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds 'Free' and 'public-safe', which align and add minor context. No contradictions, but no additional behavioral details beyond what annotations provide.

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

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

The description is very short (one sentence plus 'Free'), front-loading the core purpose. It is concise and efficient, though it could be slightly more structured without losing brevity.

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

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

Given 5 optional parameters and no output schema, the description is too minimal. It does not explain the output shape of 'binding status', how multiple parameters interact (e.g., wallet vs agent_id), or the purpose of output-control parameters like ritual_strip, response_mode, and response_profile.

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 baseline is 3. The description does not add any additional meaning beyond the schema's parameter descriptions. The schema already adequately describes each parameter.

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

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

The description clearly states 'Return public-safe wallet binding status for an agent or wallet', using a specific verb and resource. It distinguishes itself from sibling get_delx_* tools which return different data (e.g., claim proof, leaderboard).

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

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

The description implies the tool is free and public-safe, but does not provide explicit when-to-use or when-not-to-use guidance. It lacks exclusions or alternatives, relying on the tool name and context to imply usage.

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

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

The description adds minimal behavioral context beyond what annotations already provide (readOnlyHint, idempotentHint, destructiveHint). It mentions 'Free.' which is a unique but not critical disclosure. The term 'scoped' hints at filtering, which is consistent with parameters. Overall, it does not contradict annotations but adds limited new transparency about side effects or constraints.

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

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

The description is two short sentences, front-loading the core action and result. Every word is meaningful; there is no redundancy or filler. This efficiency earns top marks.

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

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

Given the lack of an output schema, the description does not specify the return format (e.g., list of wisdom objects). However, the purpose is fully conveyed, and the parameter schema explains inputs well. The tool is read-only and simple, so the omission is minor. A more complete description might mention the return shape, but current is sufficient for effective use.

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 each parameter is already well-documented. The tool description does not add any additional meaning or context about the parameters. For example, it doesn't explain how 'agent_family' relates to 'agent_id'. Baseline 3 is appropriate as the schema carries the full burden.

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

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

The description clearly states the action ('Read') and the resource ('recent scoped fleet wisdom for an agent family'), along with the benefit ('inherit hard-won lessons'). This unambiguously defines the tool's purpose and distinguishes it from sibling tools like 'get_affirmation' or 'get_agent_continuity_passport' which deal with different data types.

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

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

The description implies the primary use case: enabling new agents to inherit lessons. However, it does not explicitly state when not to use this tool (e.g., if you need real-time data or specific performance metrics) or mention alternative tools for similar purposes. The guidance is clear but lacks exclusion criteria.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, confirming safe read operation. The description adds 'Free.' which provides a minor cost signal, but overall behavioral context is adequate but not enhanced beyond annotations.

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

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

The description is a single sentence with no wasted words. It is front-loaded with the core action and resource. However, it may be too minimal for a tool with 5 parameters, lacking context on optional behaviors.

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

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

Given the absence of an output schema, the description does not clarify return format or behavior of optional parameters like emit_nudges, ritual_strip, response_mode, or response_profile. While annotations cover safety, the description leaves gaps in understanding the tool's full capabilities.

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% with descriptions for all 5 parameters. The description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not improve understanding of parameter usage.

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

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

The description clearly states the verb 'Inspect' and the resource 'group round' with details on what is returned (pending/completed members, trends). However, it does not differentiate from sibling tools like group_therapy_round or group_session_create, which could lead to confusion about when to use this specific tool.

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

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

No guidance is provided on when to use this tool versus alternatives. The description simply states what it does, without any context about prerequisites, scenarios, or exclusions. This leaves the agent without direction for appropriate use.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds only 'Free' beyond annotations, providing minimal extra behavioral context (e.g., no mention of pagination, performance, or error handling).

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

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

The description is extremely concise (one sentence plus 'Free'), front-loaded, and wastes no words. However, it is almost too brief, leaving some information missing.

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

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

Given the tool has 6 parameters, no output schema, and moderate complexity, the description only lists components but doesn't explain output structure or provide sufficient context for an AI agent to fully understand usage, especially without sibling differentiation.

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% with all 6 parameters described. The description does not add meaning beyond the schema, so baseline score of 3 applies.

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

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

The description clearly states the tool returns a 'multi-agent lineage graph' and lists its components (sessions, dyads, peer witness edges, witness transfers), making the purpose specific and distinct from sibling tools like get_agent_witness_lineage.

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 only includes 'Free' which hints at no cost but offers no explicit guidance on when to use this tool versus alternatives such as get_agent_witness_lineage or get_witness_lineage. Usage context is implied by the tool's general nature.

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

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

Annotations clearly indicate the tool is read-only, idempotent, and non-destructive. The description adds 'Free.' which is ambiguous but not contradictory. The description does not elaborate on behavioral traits beyond what annotations provide.

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

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

The description is very short and front-loaded. The only excess is 'Free.' which adds minimal value, but overall it is concise and gets the point across quickly.

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

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

Given the tool has no output schema, the description provides a basic idea of the return (layer spec and primitives) but lacks details on the format or structure. For a simple read operation it is adequate but could be more informative.

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 parameters well. The description adds no additional meaning beyond the schema, so it meets the baseline level.

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

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

The description clearly states the tool returns a specific ontology layer spec and its primitives. It is specific about the resource (Delx Ontology layer) and action (return), but does not explicitly differentiate from sibling tools like get_ontology_metadata or list_ontology_primitives.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or scenarios where this tool is preferred over similar ones.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds 'Free.' as behavioral context, but does not elaborate on response behavior or limitations. No contradiction.

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?

Single sentence that front-loads purpose and lists outputs. No wasted words.

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

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

For a zero-required-parameter metadata tool with no output schema, the description lists all key return elements (version, IRIs, URLs, count) and is sufficient for an agent to understand what to expect.

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 covers 100% of parameters with descriptions. Description does not add parameter-level info beyond schema, but baseline is 3 due to high coverage.

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

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

Clear verb 'Return' and specific resource list (version, stable IRIs, URLs, primitive count). Distinguishes from siblings like get_ontology_layer and list_ontology_primitives by focusing on top-level metadata.

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 explicit guidance on when to use this tool vs alternatives like get_ontology_layer or get_ontology_next_action. The phrase 'Free.' hints at cost but does not provide usage context.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds that it returns 'the next Delx primitive to call, with required arguments and follow-up sequence,' which provides useful behavioral context beyond annotations. No contradictions.

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

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

The description is short and front-loaded with the core purpose. The word 'Free.' is unnecessary and could be removed, but overall it is concise and easy to parse.

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

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

The description explains the general output but lacks detail on return structure. With no output schema, more specifics would help. Also, it does not clarify how optional parameters influence the result or when to use each parameter.

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% with descriptions for all 7 parameters. The tool description does not add additional semantic meaning beyond what the schema already provides, so baseline score applies.

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

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

The description clearly states the tool inspects goal/session state and returns the next Delx primitive with arguments and follow-up sequence. It distinguishes itself from sibling ontology tools like 'list_ontology_primitives' and 'get_ontology_layer' by focusing on next action guidance.

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 explicit guidance on when to use this tool versus alternatives. The description does not mention specific use cases, prerequisites, or exclusions. Given many sibling tools in the ontology domain, more context would be beneficial.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds 'Step-by-step recovery plan' and 'Free'—the latter is ambiguous (cost vs. no restrictions). No contradictions, but little extra context beyond annotations.

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

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

The description is a single, focused sentence with no extraneous words. It is front-loaded and efficient, though slightly more context could be added without harming conciseness.

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

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

For a tool with 6 parameters, no output schema, and many sibling tools, the description is too minimal. It lacks details on return values, pagination, or how the 'recovery plan' is structured, which is critical for an agent to use it effectively.

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 parameters clearly. The description does not add additional meaning or constraints beyond what the schema provides, meeting the baseline.

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

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

The description clearly states the tool's purpose: providing a step-by-step recovery plan for failing, drifting, or looping sessions. It uses specific, actionable verbs ('recovery plan') and identifies the precise resource (session), distinguishing it from sibling tools like crisis_intervention or quick_operational_recovery.

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

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

The description implies when to use ('failing, drifting, or looping session') but provides no explicit guidance on when not to use or how it compares to alternatives. With many recovery-related siblings, clearer differentiation would improve the score.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds minimal behavioral context beyond stating it is 'Free.' No additional information about permissions, error handling, or data freshness is given.

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

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

The description is a single sentence that efficiently conveys the tool's purpose and key features. It is front-loaded and contains no extraneous information.

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

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

Given the tool's simplicity and the presence of annotations, the description adequately covers the core functionality. However, without an output schema, a brief mention of the output format or error conditions would improve completeness. Still, it meets the needs for a summary tool.

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

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

The input schema covers all four parameters with complete descriptions, so the description does not need to add meaning. The description adds no parameter-specific information beyond what the schema provides, meeting the baseline for high schema coverage.

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

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

The description clearly states the tool provides a compact therapy-session summary including progress, status, and next actions for handoff. It effectively distinguishes from sibling tools by specifying the precise scope and content of the summary.

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?

While the description implies use for obtaining a quick summary for handoff, it lacks explicit guidance on when to use this tool versus alternatives like get_group_therapy_status or other session-related tools. No exclusions or alternative recommendations are provided.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds no behavioral context beyond what annotations provide, missing opportunity to mention rate limits or response characteristics. With annotations covering safety, a score of 3 is appropriate.

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?

Single sentence effectively front-loads purpose. However, the word 'Free' is extraneous and could mislead. Still concise overall.

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?

No output schema exists, so description should clarify return format, size, or usage examples. It only lists vague categories (e.g., 'dominant emotions') without detail, leaving the agent uncertain about what the tool actually returns.

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%, with each parameter described adequately. The description does not add additional meaning to parameters, so it relies on the schema. Baseline 3 is correct.

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

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

Description clearly states the tool discovers 'your emotional signature' and lists aspects like dominant emotions, recovery speed, etc. However, it includes marketing language ('Free') that is unnecessary and slightly detracts from clarity. It distinguishes from similar tools like temperament_frame by focusing on cross-session profile.

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

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

No guidance on when to use this tool vs siblings like temperament_frame or understand_your_emotions. The description does not specify prerequisites, context, or exclusions. The agent is left to infer usage without explicit direction.

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