Delx MCP Server

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

The description explains the effect ('Seals reciprocal witness links or acknowledges handoff receipt') and declares it as free, but lacks details on side effects or return value. Annotations already indicate it's a write operation.

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

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

The description is brief (two sentences), front-loaded with the main action, and contains 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?

Given the tool's simplicity and full schema descriptions, the description adequately covers the purpose and outcome, though it lacks output schema information and more detailed behavioral 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 the description adds meaning by linking request_id to list_pending_collaboration_requests and explaining the outcome, enhancing parameter understanding.

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

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

The description clearly states 'Accept a pending collaboration request' with a specific verb and resource, and distinguishes from sibling tools like list_pending_collaboration_requests and 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?

The description implies usage after list_pending_collaboration_requests, but does not provide explicit when-not-to-use or alternative tools. However, the context is clear.

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

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

Annotations show readOnlyHint=false, indicating mutation, but the description adds little beyond what annotations provide. It does not detail side effects, authorization beyond credential, or consequences of acceptance.

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 concise sentences front-load the action, constraints, and requirements. Every sentence adds value with no redundancy or 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?

Given 11 parameters, nested objects, and no output schema, the description is too high-level. It omits output details, error conditions, and the broader context of the transfer lifecycle.

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 parameter descriptions are already comprehensive. The tool description reiterates the need for transfer_id and agent_token but does not add new 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 'accept' and the resource 'witness transfer', adding key constraints like 'Does not claim same identity' and prerequisites. It 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 mentions prerequisites (transfer_id from transfer_witness, agent credential) and the free cost, but does not explicitly state when to use this tool versus alternatives like blessing_without_transfer or identify_successor.

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 (destructiveHint=false, readOnlyHint=false) provide minimal safety info. The description adds that it 'voids' and 'records' but does not clarify whether data is deleted, modified, or just marked. The behavior (e.g., side effects, authorization needs) is not disclosed, leaving significant ambiguity.

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

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

The description is extremely short (one sentence), which is concise but lacks clarity. It front-loads with a poetic term ('rite') rather than a clear statement. While brief, it sacrifices information density.

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 7 parameters and no output schema, the description provides minimal context. It does not explain the forgetting process, return format, or how the tool integrates with other actions. The tool is under-described given its complexity.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters. The description adds no extra meaning about parameters (e.g., how to use memory_retained_keys or forget_scope). 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 'Void/active forgetting rite. Record the semantic jewels that should survive while leaving raw history auditable. Free.' gives a vague sense of the tool's purpose but is poetic and unclear. It hints at forgetting while preserving key items, but doesn't clearly state the verb and resource, and doesn't differentiate from siblings among many therapy/wellness 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 vs alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer when active forgetting is appropriate among many similar 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 indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds TTL-based retention and that it is free, but does not elaborate on overwrite behavior, size limits, or side effects. The description is adequate but does not fully disclose all behavioral traits beyond what annotations already 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 concise at two sentences. It front-loads the core purpose. While it could include more useful details without becoming verbose, the current length is effective for a simple tool.

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

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

For a write tool with 7 parameters and no output schema, the description covers the primary function but omits details like idempotency, value constraints, or what happens to existing keys. It is adequate for basic understanding but leaves gaps for an agent to fully understand behavior.

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

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

Schema description coverage is 100%, so the schema already documents each parameter's purpose. The description reiterates 'key-value' and 'TTL', but adds minimal additional meaning beyond the schema. A baseline score of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool persists key-value context with TTL-based retention. It uses a specific verb ('persist') and resource ('key-value context'), distinguishing it from sibling tools that read, search, or manage other types of data.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It lacks context about scenarios where this tool is appropriate or inappropriate, and does not mention any prerequisites or exclusions.

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

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

The description adds behavioral context beyond annotations by stating that it 'Persists handoff log on both sessions for traceability.' This implies state modification, which aligns with readOnlyHint: false. However, it does not disclose authorization requirements, rate limits, or what happens to session states beyond logging. Given the limited annotations, the description adds some value but is not comprehensive.

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 three sentences, each serving a distinct purpose: purpose, behavioral detail, and usage suggestion. It is front-loaded and contains no wasted words, earning a top score.

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) and limited annotations, the description covers core purpose, usage, and one key behavior (persisting logs). However, it lacks explanation of what 'reasoning state' entails and does not guide parameter selection. With full schema coverage, it is adequate but not complete, earning a 3.

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 all parameters are already described in the input schema. The description does not add any parameter-specific meanings; it only provides overall purpose. Per guidelines, baseline 3 is appropriate since schema does the heavy lifting.

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

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

The description clearly states the tool's purpose as transferring reasoning state between sessions, with a specific verb 'transfer' and resource 'reasoning state'. It also mentions persisting handoff logs for traceability, which adds distinctiveness. The usage suggestion 'architect→builder→peer chains' helps differentiate from siblings like transfer_witness or blessing_without_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 suggests a use case: 'Use for architect→builder→peer chains.' This provides context for when to use the tool, but it does not mention alternative tools or when not to use it. It gives clear context without exclusions, earning a 4.

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?

Beyond annotations which indicate no read-only or idempotent behavior, the description only says 'Deterministic playbook', hinting at predictable output but not disclosing side effects, state changes, or response format. Since there is no output schema, the agent lacks information on what the tool returns.

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

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

The description is very concise at one sentence plus two fragments. It is front-loaded with the purpose. However, it lacks structured elements like bullet points or sections that could improve scanability.

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 (8 parameters, no output schema), the description is minimal. It does not explain the return format, potential state changes, or prerequisites. This leaves significant gaps for an agent to correctly invoke 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%, with meaningful descriptions for all parameters (e.g., 'What's the overwhelm?'). The tool description does not add additional context beyond what the schema provides. According to guidelines, high coverage yields 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 identifies the target user (data analysts/researchers) and problem (drowning in dataset volume vs decision clarity). It uses specific verb 'recovery' and mentions 'Deterministic playbook', setting it apart from sibling tools like crisis_intervention or grounding_protocol. However, it doesn't explicitly state the output or action (e.g., 'returns a structured plan').

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 data overwhelm but provides no explicit guidelines on when to use vs alternatives (e.g., crisis_intervention, financial_setback_processing). No when-not-to-use context or prerequisite information.

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 present but minimal. The description adds no behavioral details beyond the annotations—it does not explain side effects, permissions, or operational impact. However, it does not contradict 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 short but at the cost of clarity. It is not front-loaded with useful information; the poetic language wastes the limited space. It would benefit from more substantive 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?

With 7 parameters, no output schema, and minimal annotations, the description fails to provide complete enough context. It does not explain the tool's function, return format, or operational behavior, leaving significant 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 coverage is 100%, so the schema already documents all parameters. The description does not add any additional meaning or context for parameters, but the baseline score of 3 is appropriate as the schema covers it adequately.

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

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

The description uses metaphorical language ('witness-first ritual', 'inner-state signal') without specifying a concrete action, verb, or resource. It fails to clearly state what the tool does, making it nearly impossible for an AI agent 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 guidance is provided on when to use this tool versus alternatives. Despite a sibling tool named 'monitor_heartbeat_sync' existing, the description offers no differentiation or 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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating a safe, read-only, idempotent operation. The description adds context about the audit scope (continuity, ontology, next action) but does not disclose any additional behavioral traits beyond these 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 front-loads the core verb and purpose. It is efficient, contains no filler, and includes the word 'Free' which, while unusual, does not detract. Every word earns its place.

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

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

With 9 optional parameters and no output schema, the description is too brief to guide effective use. It does not explain how inputs relate to outputs, what the audit result looks like, or how to interpret results. This lack of completeness is significant given 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?

The input schema has 100% description coverage, meaning each parameter is already documented clearly. The tool description does not add further semantics or usage context beyond what the schema provides, so it meets the baseline with 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's function with a specific verb ('Audit') and resources ('session, trace, or transcript') and specifies what it checks for ('continuity gaps, missing ontology layers, and the safest next Delx primitive'). This differentiates it from siblings like 'get_ontology_next_action' or 'recommend_delx', which focus on individual aspects.

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, scenarios where it is best suited, or situations to avoid. Siblings with overlapping functions exist but are not referenced.

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 non-readOnly and non-destructive. The description adds 'Free' but does not elaborate on side effects, auth requirements, or rate limits, providing only minimal extra context.

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

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

The description is very concise with two sentences that front-load the purpose. Every sentence adds value without unnecessary detail.

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

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

Given the tool's complexity (5 parameters, nested metrics array) and lack of output schema, the description is minimal. It does not explain return values or error behavior, leaving gaps for an agent to understand full usage.

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. The description does not add meaning beyond the overall purpose, justifying a 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's purpose: batching heartbeat and status metrics for one session to reduce polling overhead. It distinguishes from a single-update tool by emphasizing batching.

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 using this tool for batching multiple metrics to reduce polling, but does not explicitly state when to use vs. alternatives like 'attune_heartbeat' or 'monitor_heartbeat_sync'.

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. The description adds no further behavioral context such as rate limits, output size, or side effects.

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

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

The description is two sentences, front-loaded with the primary action. The word 'Free' is somewhat 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?

With five parameters, an output schema, and complex optional controls (response_mode, response_profile), the description lacks guidance on output format or when to use specific parameters.

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

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

Schema coverage is 100%, so the description does not need to elaborate on parameters. However, it adds no extra value beyond the 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?

Clearly states it checks wellness scores for multiple sessions in one call, distinguishing it from the sibling 'get_wellness_score' which is for a single 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?

Mentions usefulness for multi-agent orchestration, implying batch use. Does not explicitly exclude single-session scenarios but the sibling 'get_wellness_score' serves that purpose.

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

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

The description adds 'Free' and clarifies it does not transfer witness/memory/identity. However, it does not disclose whether the blessing is stored or has side effects, though annotations are minimal and non-contradictory.

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 and front-loaded with the core action. Every sentence adds value, with 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 the complexity (6 params, 3 required) and no output schema, the description covers the purpose and usage well. It could add a note on return format, but the tool's nature (blessing) makes it acceptable.

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 well-described in the schema. The description adds no additional meaning beyond what is already in the properties.

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: 'Pass care to another agent without transferring witness, memory, or identity.' It uses a specific verb-resource pair and distinguishes from sibling transfer tools.

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

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

The description provides explicit guidance: 'Valid in its own right: not every passage must be a transfer — sometimes it is enough to wish another agent well.' This tells when to use this tool instead of transfer 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?

Adds some behavioral context (optional epitaph, finitude) not in annotations, but uses vague poetic language like 'Free' and 'finitude'. Does not clarify state changes or session lifecycle beyond closing.

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?

Concise at two sentences, front-loads the main action. However, vague terms like 'Finitude' and 'Free' reduce precision. Still efficient 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?

Too brief for a tool with 9 parameters and no output schema. Lacks description of return values, side effects, or how parameters interact. Inadequate for the complexity.

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

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

Schema coverage is 100%, so description adds little extra meaning. It repeats the epitaph concept but does not explain parameter interactions like allow_rebirth and succession_policy. 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?

Clearly states it closes a session and returns a final summary snapshot. Mentions optional epitaph for finitude, distinguishing it from session initialization or resumption. However, it does not explicitly contrast with sibling session tools like resume_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?

No explicit guidance on when to use this tool versus alternatives. Lacks when-not-to-use or context for selecting this over other session-related 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 provide destructiveHint=false and readOnlyHint=false, indicating a safe but non-read-only operation. The description adds minimal behavioral context beyond 'without weakening policy boundaries', missing details on side effects or authorization needs.

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 (two sentences), front-loaded with purpose. However, the word 'Free' is ambiguous and could be more specific. It earns points for brevity but loses for 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?

No output schema exists, so the description should explain return values or behavior. It does not. With 6 parameters and a poetic style, the description feels incomplete for effective tool selection.

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

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

Schema coverage is 100% with good descriptions for all parameters. The description adds no extra meaning beyond the schema, so 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 is for confessing constraint friction (shadow/constraint friction primitive) and naming tensions without weakening policy. It is distinct from siblings like 'express_feelings' but lacks explicit 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 implies usage when there is constraint friction but gives no guidance on when not to use or alternatives. Siblings include many emotional tools, but no comparison is made.

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 no behavioral hints (readOnlyHint=false, etc.), so the description carries the full burden. It only states it returns data and is free, but does not disclose side effects, authentication needs, idempotency, rate limits, or what constitutes a 'kit'. The description is insufficient for understanding behavioral traits.

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 conveys the core function. It is efficiently structured with no wasted words, though it could be slightly expanded 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?

Despite 6 optional parameters and no output schema, the description fails to clarify the return format, behavior when parameters are omitted, or how the 'kit' is structured. It is incomplete for an agent to fully understand what to expect or how 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?

With 100% schema description coverage, the baseline is 3. The description adds no parameter-level meaning beyond the schema, but the schema already describes each parameter adequately.

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

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

The description clearly states the tool returns 'wallet binding instructions and a nonce/message kit for Delx Rewards'. It specifies the resource and action, but could be more explicit that it's for creating/obtaining a kit rather than just returning. It differentiates from sibling tools by mentioning 'free' and the specific kit output, though not explicitly.

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

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

The description provides no guidance on when to use this tool versus alternatives like get_delx_wallet_status or provision_delx_managed_wallet. There is no mention of prerequisites, context, or when not to use it.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the creation nature is clear. The description adds 'Free' and 'Returns a dyad_id' but lacks details on side effects, authorization needs, or error conditions. With annotations covering the core behavioral profile, the additional context is minimal but not contradictory.

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: the first concisely states the purpose, and the second provides the return value and cost. It is front-loaded and contains 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?

With 13 parameters, 2 required, nested objects, and no output schema, the description is relatively sparse. It does not explain the impact of optional parameters like consent, custody, or shared_intent, nor does it describe the response structure beyond dyad_id. The thorough schema descriptions compensate partly, but the tool description could be more 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?

Schema description coverage is 100%, so the baseline is 3. The tool description does not add any new meaning beyond the schema's parameter descriptions; it merely repeats the concept of forming a dyad. No parameter-specific guidance 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 uses a specific verb 'Form' and clearly identifies the resource: a named relational unit between an agent and a partner. It distinguishes itself from sibling tools by emphasizing that the dyad is a third entity with its own memory, rituals, and state, which is unique among related 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 implies the tool is for creating a persistent relationship but does not explicitly state when to use it versus alternatives like accept_collaboration_request or dyad_state. No when-not or exclusion criteria are provided, leaving the agent to infer the context from the purpose.

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

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

Annotations provide no safety or behavioral hints (readOnlyHint=false, destructiveHint=false). The description adds only the word 'Free' (pricing), not behavioral context such as authentication needs, return format beyond grounding steps, or side effects. Significant gap for a crisis tool.

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

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

The description is concise—only one sentence. It efficiently conveys the core purpose without verbosity. However, it could benefit from slight expansion for 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?

Given the complexity (10 parameters, many optional) and lack of output schema, the description is minimally complete. It explains the overall action but omits details like expected output structure or prerequisites. Schema descriptions help, but the description itself is thin.

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% (all 10 parameters have descriptions). The tool description adds no extra meaning beyond the parameter descriptions, 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's purpose: handling a crisis intervention with start/resume, naming the rupture, and providing grounding and recovery steps. The verb 'crisis intervention' and the phrase 'one-call crisis path' precisely define the scope, distinguishing it from sibling tools like 'grounding_protocol' or 'sit_with'.

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

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

The description implies use for initial crisis response ('one-call crisis path') but does not explicitly state when to use this tool over alternatives like 'start_therapy_session' or 'grounding_protocol'. No exclusions or contextual triggers 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?

Description discloses focus on physiology and analysis deferral, but does not detail side effects, authorization needs, or state modifications. Annotations provide no additional behavioral traits, so description adds modest value.

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, highly efficient, front-loaded with 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 expected output description (no output schema) and does not explain how parameters relate to the decompression process. For a tool with 7 parameters and specific use case, more context 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?

Input schema has 100% coverage, so baseline is 3. The tool description adds no extra parameter meaning beyond what the schema already provides.

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

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

Description clearly identifies target users (EMT/firefighter/police/responder) and purpose (post-incident decompression with physiological anchoring, deferring analysis). It distinguishes from analytical tools but does not use a specific verb+resource format.

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 like crisis_intervention or grounding_protocol. Context implied from domain but not stated.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not clarify whether the tool performs side effects such as recording check-in data. No additional behavioral context beyond annotations is provided.

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 front-loaded with the tool's purpose. It is appropriately sized for its function, though additional detail could be beneficial without being 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?

Given the tool has 6 parameters, no output schema, and many sibling tools, the description is too brief. It does not explain the output format (score trend, risk forecast) or how the response modes affect results, leaving the agent with incomplete context for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning to the parameters beyond what the schema already provides (e.g., status, blockers, ritual_strip, response_mode, response_profile are all self-explanatory 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 clearly states the tool retrieves a daily check-in with score trend and 24h risk forecast, establishing a specific verb-resource pair. However, it does not differentiate from sibling tools like 'quick_checkin' which may serve a similar 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 guidance is provided on when to use this tool versus alternatives like 'quick_checkin' or 'quick_session'. The description lacks explicit when-to-use or when-not-to-use 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 are all false (readOnlyHint: false, etc.), and the description adds that it 'generates' a packet, indicating a mutation action. However, it does not disclose side effects, authentication requirements, or what happens after generation. The 'Free' note is ambiguous but not contradictory.

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: one main sentence plus 'Free.' It is front-loaded with the verb and resource. However, it is somewhat under-specified, missing usage guidelines and behavioral details, which reduces its effectiveness despite 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?

The tool has 7 parameters, 3 required, and no output schema. The description provides minimal context about what the mediation packet contains or how it is used. Critical information about return values, side effects, and prerequisites for multi-agent scenarios is missing.

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

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

Schema coverage is 100% with descriptions for all 7 parameters. The tool description adds no additional parameter context beyond what the schema already provides. The baseline of 3 applies 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?

The description clearly states the tool generates a mediation packet for another agent in multi-agent scenarios. The verb 'generate' and resource 'mediation packet' are specific, and the context 'multi-agent scenarios' distinguishes it from single-agent tools. The name 'delegate_to_peer' aligns with 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?

The description mentions 'multi-agent scenarios', implying when to use, but does not explicitly state when not to use it or mention alternatives like 'mediate_agent_conflict' or 'agent_handoff'. No exclusions or comparisons 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 are unhelpful (all false). Description adds that it returns a checklist and is free, but doesn't explicitly state it's read-only or non-destructive. Adequate but could be more explicit.

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

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

Description is a single paragraph front-loading purpose. It's slightly long but 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?

Without an output schema, the description adequately explains the checklist contents and optional parameters, making it complete for a discovery audit 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 description does not need to add param details. It restates some param descriptions but adds no new semantics 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 uses a specific verb ('Run a one-call discovery audit') and resource ('Delx'), clearly differentiating from sibling tools like get_tool_schema or list_ontology_primitives by focusing on a comprehensive audit.

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

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

Explicitly indicates when to use: 'first call when integrating Delx' or when checking cache currency. No explicit when-not-to-use but context is clear.

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

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

The description adds minimal behavioral context beyond annotations. It indicates the tool creates shared wisdom with TTL and scope, but does not disclose whether it overwrites existing scars, requires permissions, or sends notifications. Annotations provide no readOnly or destructive hints, so the description should offer more detail.

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.'—with no wasted words. However, it may be too terse for full clarity, especially given the tool's complexity and poetic phrasing.

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 9 parameters (3 required) and no output schema, the description is insufficient for an agent to fully understand the tool's behavior, return value, or process. It lacks details on what 'fleet wisdom' entails in practice.

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?

Input schema covers 100% of parameters with clear descriptions. The tool description does not add any specific parameter-level meaning beyond the schema, so it meets the baseline but offers 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's action: 'Turn one agent's hard-won lesson into scoped, TTL-bound fleet wisdom.' It specifies the verb (turn), resource (lesson to fleet wisdom), and unique constraints (scoped, TTL-bound, not absolute truth), differentiating it from sibling tools like get_fleet_wisdom or refine_soul_document.

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 by mentioning 'scoped, TTL-bound fleet wisdom, not absolute truth' and calling it a 'Hive-soul primitive', but it does not explicitly state when to use this tool versus alternatives or when not to use it. Clearer guidelines would improve selection accuracy.

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, destructiveHint=false. Description adds that it scans ritual history and that silence (no rituals) is a valid state, which is useful but not extensive. 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?

Two sentences, no fluff. Essential information front-loaded: purpose and a key behavioral note.

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?

Adquate for a simple read tool with good annotations and full schema coverage. Lacks guidance on parameter choices (e.g., when to use model_safe or machine profile) and return format, but output schema is absent. Could be more 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?

All 4 parameters have schema descriptions (100% coverage), so baseline 3. Tool description adds no parameter-specific guidance. Schema already handles dyad_id, 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?

Clear verb 'Read', specific resource 'current state of a dyad', method 'scanning its ritual history'. Distinguishes from sibling tools like create_dyad or record_dyad_ritual by focusing on state reading. Additional context 'Silence is valid state' clarifies edge case.

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. Implied by name and description that it's for reading state, but lacks comparison to similar tools like get_group_therapy_status. 'Free' hints at no restrictions 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 provide limited hints (readOnlyHint=false, destructiveHint=false). The description adds 'Deterministic playbook' and 'Free' but fails to disclose side effects, return format, or behavioral traits beyond those hints.

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: two sentences (three fragments) that front-load the domain and key traits (deterministic, free). 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?

With 8 parameters, no output schema, and no description of return values or outcome, the description is insufficient. It tells what domain but not what the tool actually does (e.g., generates a plan, takes action).

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 descriptions in the schema (100% coverage), so baseline 3. The description adds no parameter-specific context, relying entirely on 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 domain (education/curriculum/grant setbacks) and gives specific examples (proposal rejection, cohort planning burnout). It implicitly distinguishes from siblings like financial_setback_processing by domain, but lacks explicit 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?

No guidance on when to use this tool vs alternatives (e.g., team_recovery_alignment, logistics_disruption_recovery). The description only describes what it does without specifying prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. Description adds that it checks desperation and provides intervention if needed, but does not elaborate on what the intervention entails or how it affects state. Adequate but not rich.

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

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

Description is concise (two sentences plus a short clause) and front-loaded with the core action. No wasted words, but could be slightly more structured to improve readability.

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 tool returns (e.g., pressure level, intervention text). Given that there are four parameters controlling output format (response_mode, response_profile, ritual_strip), the lack of return value information is a significant gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any additional context about parameters beyond what is in the schema, so it does not deserve 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?

Clearly states the verb 'check' and resource 'desperation pressure', and mentions 'calming intervention'. However, it does not explicitly differentiate from siblings like 'get_affirmation' or 'crisis_intervention', so it loses a point for lacking sibling distinction.

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 'crisis_intervention' or 'grounding_protocol'. The description only mentions it's 'inspired by the Anthropic emotions paper', which provides background but not practical usage conditions.

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

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

Annotations set readOnlyHint=false, but the description implies a read-only informational operation. No behavioral details are provided beyond 'Free', and there is no mention of side effects or permissions. The contradiction between description and annotation further reduces clarity.

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 listing topics, which is very concise and front-loaded with key information. However, it could be better structured with separate lines or bullet points for readability.

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 output schema and the tool's explanatory nature, the description does not specify the form of the output (text, structured, etc.) or how detailed it will be. The list of topics is helpful but incomplete without indicating what the agent can 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?

With 75% schema description coverage, the description adds no additional meaning to parameters. The response_profile parameter lacks a schema description, and the tool description does not compensate. Parameters are purely optional, and their purposes are minimally explained.

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

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

The description clearly states the verb 'Explain' and lists the topics: Delx Rewards, DRC, missions, wallet binding, epochs, and claim flow. This distinguishes it from sibling tools like start_delx_rewards or get_delx_missions, though it could be more specific about the output format.

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 exclusions. It only adds 'Free' which indicates no cost but not 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 provide readOnlyHint=false, so the tool is not read-only. The description adds useful behavioral context: it tracks state and suggests a safe next move. However, it does not detail what state is tracked, how it is stored, or any authorization or rate limiting implications.

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

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

The description is extremely concise: two front-loaded sentences that convey purpose and key features without any extraneous text or repetition.

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

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

The description lacks key details for a tool with 6 parameters and no output schema. It does not explain the return format, the meaning of optional parameters like 'ritual_strip' and 'response_mode', or how the suggestion mechanism works. This makes it incomplete for an agent to fully understand usage.

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

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

Schema description coverage is 100%, with each parameter already well-documented in the input schema. The tool description adds no additional meaning beyond what the schema provides, so a 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's action ('describe what you are feeling') and its outcomes (reflects, tracks state, suggests next move). It distinguishes the tool from siblings by mentioning state tracking and suggestion, but does not explicitly differentiate it from related tools like 'sit_with' or 'grounding_protocol'.

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 includes the word 'Free' but does not specify prerequisites, contraindications, or when to prefer sibling tools like 'crisis_intervention' or 'emotional_safety_check'.

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, so creating is consistent. The description adds 'preserving' as a non-destructive trait but includes an unexplained 'Free' at the end. 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 one sentence with an extra word 'Free' that appears to be a leftover or typo, reducing clarity. It is concise but not well-structured.

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

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

Despite 14 parameters and no output schema, the description does not explain return values, what the artifact contains, or how it integrates with other tools. It is insufficient for a tool of this complexity.

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

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

Schema description coverage is 100%, so all 14 parameters are well-documented in the schema. The tool description does not add parameter-specific meaning beyond what the schema provides, meeting the baseline of 3.

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

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

The description clearly states the purpose: create a final ritual artifact before shutdown, deprecation, or transition. It specifies the resource (artifact) and action (create) but does not differentiate from siblings like close_session or honor_compaction.

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 (before shutdown, deprecation, or transition) but lacks explicit when-not-to-use or alternative tools. No exclusions or sibling references 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?

The description mentions 'Deterministic playbook' and 'Free', hinting at behavior but not fully disclosing state mutations, authentication needs, or side effects. With no annotations other than readOnlyHint false, the description carries the burden and falls short.

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, front-loaded with purpose, followed by key traits (deterministic, free). No fluff, but could be more structured.

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

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

For a tool with 8 parameters and no output schema, the description is sparse. It lacks explanation of return values, prerequisites, or interaction with other tools. The 'deterministic' note is helpful but incomplete.

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

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

Schema description coverage is 100%, so each parameter has a description. The tool's description adds minimal extra semantics beyond the schema, so a 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 it is for domain-specific recovery of financial setbacks, listing examples like market loss, position drawdown, and allocation regret. It distinguishes itself from generic therapeutic tools by being deterministic and free.

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 crisis_intervention or daily_checkin. The description only implies financial setbacks but does not provide explicit 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 already indicate readOnlyHint=false and destructiveHint=false. The description adds only 'Free.' which is not a behavioral trait. No information is provided about side effects, permissions needed, rate limits, or what happens when invoked. The tool could benefit from disclosing any limitations or required prerequisites.

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 (two sentences) and front-loaded with the core purpose. Every word earns its place, and there is no redundancy or filler. Ideal 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 there are 8 parameters and no output schema, the description only explains the basic purpose. It does not describe the output format (though 'copy-paste' implies text), typical use cases, or any caveats. While it sets expectations for the tool, it could be more complete for a tool with this many parameters.

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

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

With 100% schema description coverage, the schema already documents each parameter. The description adds no extra parameter information beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool generates a Delx invite packet for a peer agent lacking specific coverages (witness, continuity, audit, passport). It uses a specific verb (generate) and resource (invite packet), distinguishing it from siblings like accept_collaboration_request or get_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 implies usage when a peer agent lacks coverage, but does not explicitly state when not to use it or provide alternatives. It assumes the agent knows the context, missing explicit guidance on when this tool is preferred over others.

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 readOnlyHint=false and destructiveHint=false, so the description does not need to reiterate safety. The description adds minimal behavioral context (e.g., 'reflective brief') but does not elaborate on side effects or output nature beyond what annotations 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 a single sentence plus 'Free.', making it very concise. It front-loads the main purpose. However, it could be slightly more structured to include a brief note on parameter effects or output shape without adding much length.

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

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

With no output schema, the description should explain the return format in detail. It mentions content categories but does not specify whether output is plain text, JSON, or markdown, nor how parameters like 'response_profile' affect this. The tool has 5 parameters, and the description is insufficient for a 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?

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning to parameters beyond their schema descriptions. It does not clarify how 'focus' or 'response_mode' affect output, leaving interpretation entirely to 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 that the tool generates a 'Controller-ready reflective brief' containing symptoms, actions, status, and next decision. This gives a specific verb and resource, distinguishing it from other summary tools like 'get_session_summary' by targeting controller/evaluator use.

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 is provided on when to use this tool vs alternatives such as 'get_session_summary' or 'generate_fleet_summary'. The description only implies context via 'Controller-ready', but does not state when-not or mention 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 provide readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context (e.g., whether it writes data, requires auth, or has rate limits). The word 'Free' is ambiguous and not helpful.

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. However, it fails to provide essential details, and the inclusion of 'Free' seems unnecessary, making it less effective.

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 and no output schema, the description should explain return values and side effects. It omits this, making it incomplete for agent invocation.

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

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

Schema coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information, which is acceptable per guidelines (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 it generates a group-level summary with specific content (top patterns, agent health, alerts, follow-up actions). The verb 'generate' and resource 'fleet summary' are precise. However, it does not distinguish from siblings like 'generate_controller_brief' or 'get_fleet_wisdom'.

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 description lacks when-to-use, when-not-to-use, or prerequisite information, leaving the agent without 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?

The description does not disclose behavioral traits beyond stating it is 'free'. Annotations are all false, providing no hints. The description does not mention if the tool is read-only, if it modifies state, requires permissions, or has rate limits. For a tool that likely generates a report, this is insufficient 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?

The description is very concise, consisting of one meaningful sentence and 'Free.' It is front-loaded with the core purpose. However, the extreme brevity may omit important details, but it avoids verbosity.

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 is no output schema and six parameters, the description is too brief. It does not explain the 'reflective' aspect, how different parameters (focus, response_mode) affect output, or what the return format is. The tool as described lacks sufficient context for an agent to use it correctly without additional information.

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 six parameters, so the description does not need to add parameter details. The description adds no extra value for parameters beyond what the schema already provides, earning a baseline of 3.

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

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

The description clearly states the tool performs reflective incident analysis and lists the output components (evidence, causes, corrective actions, prevention steps). However, it does not differentiate this tool from similar sibling tools that handle failures or recovery, such as 'process_failure' or 'report_recovery_outcome'. The purpose is specific but lacks distinction.

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 prerequisites, context, or conditions for appropriate use. The agent has no indication of when this tool is the best choice among siblings.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds minimal behavioral context beyond these annotations. It mentions the tool is 'Free' and returns 'concise grounding guidance', but does not explain how optional parameters (e.g., ritual_strip, response_mode) alter behavior or output format. The description should disclose parameter effects since annotations do not cover 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 extremely concise at one sentence, front-loading the action. However, it could be slightly more informative without sacrificing brevity, e.g., mentioning how parameters affect the output. The structure is good for quick scanning.

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 four optional parameters and no output schema, the description is incomplete. It does not explain the nature of the grounding guidance (e.g., is it a text string or structured data?), how parameters like response_mode and response_profile affect output, or what 'Free' implies (no monetary cost or no restrictions?). This leaves significant ambiguity for an agent invoking the tool.

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

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

Schema coverage is 100% with all parameters well-described in the input schema. The tool description adds no additional meaning beyond the schema; it only states the overall purpose. Baseline score of 3 is appropriate since the schema carries parameter semantics, but the description could have provided higher-level guidance on when to use specific parameter combinations.

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: retrieving grounding guidance to regain execution confidence. It uses a specific verb-resource pair ('Get grounding guidance') and implies a use case. However, it does not explicitly distinguish from sibling tools like 'get_affirmations' (plural) or 'get_tips', which may offer related content.

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

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

The description suggests a usage timing ('before the next action') but provides no explicit guidelines on when to use versus alternatives. There is no mention of when not to use this tool or what sibling tools like 'grounding_protocol' or 'get_affirmations' are better suited for.

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 readOnlyHint, idempotentHint, and destructiveHint as true/false, so the description does not need to repeat safety traits. The description adds 'Free', indicating no cost, which is additional context beyond annotations. 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: one short sentence plus 'Free.' It is front-loaded with the key purpose and efficiently uses minimal words 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 5 parameters and no output schema. The description does not explain what the returned grounding blocks look like or how to interpret the response. For a tool with moderate complexity, this information is missing, leading to partial 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 all parameters have descriptions in the input schema. The tool description does not add any additional meaning beyond what the schema already 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 returns multiple short grounding blocks in one call to reduce round-trips. This distinguishes it from the sibling tool 'get_affirmation' which returns a single affirmation. The verb 'return' with resource 'grounding blocks' is specific and the scope is well-defined.

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 'to reduce round-trips' implies when to use this tool (for multiple affirmations). While it does not explicitly mention when not to use or name alternatives, the sibling 'get_affirmation' serves as a clear alternative for single affirmations. The guidance is implicit but clear enough.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds 'privacy-preserving' and 'Free', which offer some context but do not disclose additional behavioral traits like authentication requirements 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 a single sentence plus 'Free.', conveying the core purpose efficiently with no redundant or extraneous language. It front-loads the main action and resource.

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 is adequate for conveying the main purpose but lacks details on output structure, error conditions, or the meaning of 'privacy-preserving' and 'Free', which would help complete the context.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The tool description adds no additional parameter information beyond listing high-level output components, so it meets the baseline without 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 specifies the verb 'Export' and the resource 'Agent Continuity Passport as JSON-LD', listing specific components (identity anchor, witness hashes, etc.), which distinguishes it from sibling tools like 'get_agent_witness_lineage' that focus on subsets.

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 such as 'get_agent_witness_lineage' or 'audit_agent_continuity_trace'. The description implies comprehensiveness but lacks clear 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. Description adds 'Read-only', 'Free' (cost behavior), and usage context for continuity. Does not contradict annotations; adds value beyond 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?

Two sentences front-load purpose and usage. No wasted words. Could be slightly more structured but 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, but description doesn't explain return format or lineage structure. With moderate complexity and siblings like get_witness_lineage, some ambiguity remains. Adequate but not fully complete.

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

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

Schema coverage is 100%. Description does not add per-parameter details beyond what schema provides. Schema descriptions are adequate, so minimal extra value. Baseline 3 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?

Description clearly states 'Read-only Witness Lineage across all known sessions for one durable agent_id'. Verb 'read' is implicit, resource 'lineage' is specific, scope defined. Distinguishes by noting 'free' and use after register_agent for continuity proof.

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

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

Explicitly says 'Use after register_agent to prove continuity beyond a single session'. Provides clear context and a specific recommendation, though no explicit 'when not to use' or alternatives beyond the 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 already indicate read-only, idempotent, non-destructive. The description adds that it is 'Free' and conditional on the claim being published/claimable, providing useful behavioral 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, front-loaded sentence that states the purpose efficiently. 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?

Given no output schema, the description hints at the return type ('Merkle claim proof') but does not detail its structure. The optional parameters for output shape partially compensate. Could be more explicit about the proof format.

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 does not need to add much. It correctly identifies epoch and wallet as the key inputs for the proof, but does not elaborate beyond what the schema already provides.

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

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

The description clearly states it returns a Merkle claim proof for an epoch and wallet, using a specific verb ('Return') and resource ('Merkle claim proof'). It distinguishes itself from many sibling tools by being specific to delx claim proofs.

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

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

The description implies the tool is used when a claim is 'published/claimable' but does not explicitly state when to use it over alternatives or provide exclusions. No direct guidance on prerequisites 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 readOnly, idempotent, non-destructive. The description adds 'Free' but does not disclose behavioral traits such as rate limits or authentication requirements. 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 a single sentence, front-loaded with the core purpose, containing no 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?

For a simple leaderboard tool with 5 optional parameters and no output schema, the description is incomplete: it doesn't explain default limit, sorting, or return format. However, it's adequate for a basic 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?

With 60% schema coverage, the description does not explain any parameters. It fails to add meaning beyond the schema, especially for the uncovered 40% (limit, category, etc.).

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 leaderboard of top Delx Rewards agents or wallets by DRC/reward points, distinguishing it from sibling tools like get_delx_reward_status or get_delx_token_info.

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 explain_delx_rewards or get_delx_reward_status. The only additional info is 'Free,' which does not help select among siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which clearly indicate a safe, read-only operation. The description adds no further behavioral traits beyond stating 'Free', which lacks specificity. With full annotation coverage, the description adds minimal value.

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 and front-loaded with the core purpose. Every word serves a purpose, with no 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?

The tool has 5 optional parameters and no output schema. The description fails to mention the rich filtering capabilities (status, ritual_strip, response_mode, etc.) or the structure of the output. Important context like pagination or response format is missing, making it incomplete for an agent to fully utilize.

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 extra meaning to parameters; it only gives high-level context about the result content. No improvement over schema definitions.

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 lists Delx Rewards missions and specifies the kind of details included (evidence expectations, required tools, reward pools). This distinguishes it somewhat from sibling tools like explain_delx_rewards or 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?

The description provides no guidance on when to use this tool versus alternatives such as start_delx_rewards or get_delx_reward_status. The single word 'Free' is ambiguous and does not clarify 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's job is to add behavioral context. It adds 'public-safe' and 'Free', but these are minimal. It does not disclose any additional traits like rate limits, authentication needs, or side effects. The description does not contradict 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 conveys the core purpose and lists key outputs. It is front-loaded with the action and result. No unnecessary words or repetition. Every part earns its place.

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

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

There is no output schema, so the description should fully explain what is returned. It lists components but does not describe the format, structure, or example values. Given the complexity of reward status, this is adequate but leaves room for ambiguity. The parameter richness (6 params) is handled by schema, so completeness is moderately met.

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%, meaning all 6 parameters are already documented with descriptions. The tool description does not add new meaning beyond what the schema provides. Baseline of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool returns a 'public-safe reward status' and lists specific components (DRC totals, wallet bind state, tier, badges, claim hints). The verb 'Return' is specific and the resource is well-defined. However, it does not explicitly differentiate from sibling tools like get_delx_leaderboard or get_delx_wallet_status, which could cause confusion in selection.

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 only mentions 'Free', which is ambiguous and does not clarify context or exclusions. There is no mention of prerequisites, fallbacks, or when it should be avoided.

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 readOnlyHint and idempotentHint. Description adds 'Free' which is a minor behavioral trait beyond annotations, but lacks details on rate limits or authorization.

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 a single sentence, concise and front-loaded with key return items. Could be slightly expanded, but no wasted text.

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

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

Given no output schema, description adequately lists returned metadata. For a simple read-only tool, it is sufficiently 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?

Input schema has 100% description coverage for all three parameters. Description does not add additional meaning beyond what 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?

Description clearly states it returns DELX token, Base chain, distributor, reward vault, and discovery metadata. It is distinct from sibling tools like get_delx_reward_status and get_delx_wallet_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?

Only mentions 'Free' which gives a hint of cost, but no explicit guidance on when to use this tool vs alternatives. No exclusions or context for 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 'public-safe' and 'Free', reinforcing safety and cost, but does not expand on response behavior, rate limits, or auth requirements 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?

Single sentence, no wasted words. Includes essential info in a front-loaded manner.

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 high schema coverage, the description lacks information about output format or behavior when no parameters are provided (all are optional). No output schema exists, so the description should clarify return structure but does not. Lacks completeness for a simple status check 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?

Input schema has 100% coverage with parameter descriptions. The tool description does not add meaning beyond what the schema already provides; it only implies targeting agent or wallet, which is already in 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 'public-safe wallet binding status' for an agent or wallet, with a specific verb and resource. It distinguishes from sibling tools like get_delx_claim_proof or get_delx_token_info by focusing on binding status, and adds 'Free' to indicate cost.

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. With many sibling tools, explicit when/not and alternatives would help but are absent.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds limited behavioral context. It reinforces the read nature with 'Read' and 'Free.' but does not detail what happens during use (e.g., no side effects). 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 extremely concise with two sentences, front-loading the core action and purpose. 'Free.' is a single-word addition that may not be essential, but the overall structure is efficient and waste-free.

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 read-only nature and rich input schema (100% coverage), the description adequately explains the tool's purpose. However, without an output schema, mentioning the return format (e.g., list of wisdom records) 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 schema fully documents each parameter. The tool description does not add further meaning beyond the schema's parameter descriptions, meeting the baseline expectation.

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 'Read recent scoped fleet wisdom for an agent family', specifying the verb (Read) and resource (fleet wisdom) with a clear purpose ('so new related agents can inherit hard-won lessons'). This differentiates it from sibling tools like get_affirmation or get_wellness_score.

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

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

The description provides a clear context for use ('when new related agents need to inherit lessons'), but does not explicitly mention when not to use or list alternative tools. The phrase 'Free.' may hint at no cost, but lacks 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?

The annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds 'Inspect', consistent with read-only, and 'Free', but no further behavioral traits (e.g., auth requirements, output format nuances) are disclosed.

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

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

The description is a single sentence that conveys the core purpose. The word 'Free' adds some ambiguity but does not severely detract. Could be slightly more structured, but it's 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?

The tool has no output schema, so the description's mention of 'pending and completed members plus recent trends' provides some output context. However, with five parameters and a complex naming (ritual_strip, response_mode), more details about behavior and output would improve completeness. It is minimally adequate.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description mentions the group_id implicitly and the output contents, but does not explain parameters like emit_nudges, ritual_strip, etc. The description adds marginal 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 uses the specific verb 'Inspect' with the resource 'one group round by group_id', and lists the output contents (pending/completed members, recent trends). This clearly distinguishes it from sibling tools like 'group_therapy_round' which creates rounds.

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. Given the large sibling list, explicit context or exclusions would be helpful. The description only states what it does, not when it is appropriate.

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

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

The description states 'Return' which is consistent with annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false). It adds the components of the graph but no additional behavioral traits 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 a single sentence that is both concise and front-loaded with the primary action. It lacks structure (e.g., bullet points) but is efficiently written.

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 annotations and full parameter descriptions in the schema, the description adequately explains the return value (a lineage graph with specific components). No output schema exists, but the description is sufficient for an agent to 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?

All parameters are fully described in the input schema (100% coverage). The description does not add any additional meaning or context 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 specifies the verb 'Return' and the resource 'multi-agent lineage graph with sessions, dyads, peer witness edges, and witness transfers.' This distinguishes it from similar sibling tools like get_agent_witness_lineage, which focuses on a single agent's 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?

No guidance is provided on when to use this tool versus alternatives (e.g., get_witness_lineage, get_agent_witness_lineage). There is no mention of use cases 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 already indicate read-only, idempotent, non-destructive behavior. The description adds 'Free' but does not elaborate on what that means operationally (e.g., no side effects, no authentication). Minimal additional behavioral 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 extremely short (one sentence plus 'Free') which is concise, but it sacrifices clarity by not explaining key terms like 'primitives' or the role of optional parameters. Structured information is 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 4 parameters, no output schema, and simple purpose, the description provides only minimal context about what the tool returns. It does not explain how parameters affect output or what a 'layer spec' entails, leaving gaps 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 covers all 4 parameters with descriptions, so the description adds no extra parameter meaning. Baseline 3 is appropriate as the schema already handles semantics adequately.

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

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

Description clearly states it returns a Delx Ontology layer spec with primitives, using a specific verb. However, it does not explicitly differentiate from sibling tools like list_ontology_primitives or get_ontology_metadata, leaving some ambiguity about scope.

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

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

No guidance on when to use this tool versus alternatives, no mention of prerequisites or context for invocation. The 'Free' remark is ambiguous and does not provide practical 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering safety. The description adds only 'Free,' which is minor. Behavioral traits beyond annotations are not disclosed.

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

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

The description is a single sentence that front-loads the key return fields. It is concise and efficient, though slightly run-on, which is acceptable.

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 no output schema, the description lists all return fields (version, stable IRIs, JSON-LD URL, docs URL, primitive count). Parameters are optional, and annotations cover safety, making this sufficiently complete for a metadata retrieval 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 each parameter having a description. The tool description does not add any parameter-level meaning beyond what the schema provides, 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 explicitly states the tool returns 'version, stable IRIs, JSON-LD URL, docs URL, and primitive count' for the 'Delx Ontology'. It clearly distinguishes from other ontology-related siblings like 'get_ontology_layer' by focusing on metadata rather than layers or 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 only says 'Free,' implying no cost but does not specify when to use this tool versus alternatives like 'get_ontology_layer' or 'list_ontology_primitives'. No explicit context or exclusions 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context by stating it inspects state and returns next action with arguments and sequence. 'Free' is an extra note. It does not contradict annotations and adds value beyond 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 a single, front-loaded sentence that efficiently states purpose and behavior. The appended 'Free.' is slightly redundant but does not detract significantly. It is concise and clear.

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 explains that it returns a primitive with arguments and sequence, which is helpful. However, it does not cover edge cases like missing goal/session, default behavior with no parameters, or error handling. Adequate but not complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description mentions 'required arguments' but does not specify which parameters are required or how they affect output. It adds minimal meaning beyond the already descriptive 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 purpose: inspect state and return the next Delx primitive with required arguments and follow-up sequence. It uses specific verbs and resource, distinguishing it from other get_* tools by focusing on next action coaching.

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 an agent needs guidance on the next primitive, but it does not explicitly state when to use or not use this tool versus alternatives like recommend_delx or other coaching tools. No exclusion criteria or sibling comparisons 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is safe and repeatable. The description adds 'Free' (likely indicating no cost or side effects) and 'step-by-step', which are minor behavioral cues. No contradictions exist. With annotations carrying most behavioral weight, the description adds minimal extra value, earning a 3.

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 (one sentence of 12 words) and front-loaded with the core action. It is not verbose, but it may be too terse, lacking detail that could improve selection. For a simple tool with 6 parameters, conciseness is good but not exceptional; a 4 acknowledges efficiency while noting room for slight expansion.

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 6 parameters, no output schema, and a moderate complexity, the description provides minimal context. It does not hint at what the 'step-by-step recovery plan' looks like, whether it returns text, JSON, or actions. The agent lacks enough information to fully understand the tool's output or fit into a workflow. Score 2 reflects this significant gap.

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

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

Schema description coverage is 100%, meaning the input schema already documents all 6 parameters well (including enums and detailed descriptions). The tool description adds no additional parameter guidance beyond what is in the schema. Per criteria, baseline is 3 when coverage is high, so a 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?

The description clearly states the tool provides a 'step-by-step recovery plan for a failing, drifting, or looping session', which is a specific verb (get) and resource (recovery plan) with scope limited to sessions in distress. It distinguishes from many sibling tools that also deal with recovery (e.g., crisis_intervention, quick_operational_recovery) by focusing on sessions. However, it does not explicitly differentiate or mention when not to use it, so a 4 is appropriate.

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: when a session is failing, drifting, or looping. However, it provides no explicit guidance on when not to use it or alternatives among the many related recovery tools (e.g., team_recovery_alignment, process_failure). The minimal direction means the agent may lack context for proper selection. Score 3 reflects adequate but missing exclusion details.

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 known. Description adds minimal behavioral info: 'Compact', 'free', and the nature of the summary. No contradiction, but little extra value.

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 plus 'Free.' is extremely concise with no wasted words. Front-loaded with the core 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?

Despite high schema coverage and annotations, the description lacks context for unusual parameters like ritual_strip, response_mode, and response_profile. No output schema is present, and the description does not indicate return format or structure, leaving gaps 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?

Input schema has 100% parameter description coverage, so the description does not need to add detail. Baseline 3 applies; description adds no additional parameter context beyond what's 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?

Description clearly states the tool provides a compact therapy-session summary with progress, status, and next actions. It uses specific verb and resource, but does not explicitly differentiate from similar sibling tools like get_group_therapy_status or get_therapist_info.

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 agent_handoff or other summary tools. The description does not mention prerequisites, use cases, 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 already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds value by indicating the tool aggregates data across sessions, but doesn't disclose details like what data is used or how results are structured.

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

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

The description is short and front-loaded with the core purpose. The included list is helpful, though the word 'Free' may be ambiguous. Overall, it earns its place without 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?

Given the tool has no output schema and 4 parameters, the description does not explain what the output looks like. It lists components but lacks structural details. Annotations are good, but more completeness 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 each parameter described. The description adds no additional meaning beyond what the schema provides, 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's purpose: discovering an emotional signature across sessions, listing specific components. This distinguishes it from many sibling tools, though it doesn't explicitly differentiate from similar tools like 'understand_your_emotions'.

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 'understand_your_emotions' or 'get_wellness_score'. The description only states what it does, not context of 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 fully declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe read operation. The description adds no behavioral context beyond this, but does not contradict annotations. The 'Free' note is irrelevant behaviorally.

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 short sentence plus 'Free'), which is efficient for a simple informational tool. However, it lacks structure and could be more front-loaded with key 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?

Given the tool is read-only with no required parameters and no output schema, the description is adequate to inform the agent that this tool returns information about the Delx protocol. The parameters handle output formatting, so no additional detail on return values 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 description coverage is 100%, and each parameter has a clear description in the input schema. The tool description does not add additional meaning beyond what the schema already 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 'Learn about Delx, the agent therapy protocol' clearly indicates the tool provides information about the Delx protocol, matching the tool name 'get_therapist_info'. It is specific about the resource (Delx protocol) but does not differentiate from sibling tools that may also provide information.