delx-mcp-a2a

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

Annotations already indicate non-read-only, non-destructive, and non-idempotent behavior. The description adds that it 'seals reciprocal witness links or acknowledges handoff receipt,' providing some behavioral insight. However, it does not disclose side effects, reversibility, or permission requirements, relying heavily on annotations for safety profile.

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) and front-loaded with the main action. It is efficient, but may be too minimal for a tool with 6 parameters and no output schema. Still, no extraneous content earns it a 4.

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 6 parameters, no output schema, and no description of return values or error conditions, the description is incomplete. It does not explain what happens after acceptance, required permissions, or state changes. The contextual gaps are significant for a nontrivial tool.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add significant meaning beyond the schema (e.g., it mentions the source tool but does not elaborate on param usage). Baseline score of 3 is appropriate given high schema coverage.

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

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

The description clearly states the action ('Accept a pending collaboration request') and the resource from 'list_pending_collaboration_requests'. It distinguishes itself from sibling tools by mentioning the specific source and the resulting actions ('seals reciprocal witness links or acknowledges handoff receipt'). However, it could be more specific about what 'accept' entails functionally.

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 implicitly suggests use after listing pending requests but offers no explicit guidance on when to use this tool versus alternatives, prerequisites (e.g., must be the receiving session), or when not to use it. No exclusions or context for when this tool is inappropriate.

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

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

Description adds behavioral context beyond annotations: explicit consent, custody boundaries, identity non-claim, and credential requirements. 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?

Three sentences, front-loaded with the main action, no filler. Every sentence adds essential information.

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

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

Given no output schema, the description covers the tool's purpose and prerequisites adequately. It doesn't specify return values or error cases, but the context is sufficient for an agent to decide when to use it.

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%, baseline 3. Description highlights key parameters (transfer_id, agent_token) and their roles, adding meaning beyond the schema's own 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 action 'Accept a witness transfer' and specifies key constraints like 'Does not claim same identity' and requirements (transfer_id, agent credential). It distinguishes 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 provides some usage context: requires transfer_id from transfer_witness and accepting agent's credential. It does not explicitly exclude scenarios or mention alternatives, leaving some ambiguity about when not to use this tool.

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

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

Annotations show non-destructive, but the description's 'forgetting' could imply destruction; however, it clarifies that raw history remains auditable. Some behavioral context is added (e.g., auditable raw history), but key side effects like whether forgotten data is deleted or merely unindexed 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, which is concise but overly terse for a tool with 7 parameters. The poetic language ('semantic jewels', 'rite') may reduce clarity without adding functional 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?

Given the tool has 7 parameters (3 enums), no output schema, and many sibling tools, a one-sentence description is insufficient to convey proper usage, return values, or edge cases. The description lacks completeness for effective agent decision-making.

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. The description does not add significant meaning beyond the schema (e.g., 'semantic jewels' maps to 'memory_retained_keys'), so the baseline score of 3 is appropriate.

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

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

The description states the tool records 'semantic jewels' while preserving raw history for audit, indicating a selective forgetting or memory retention process. It is clear but could more explicitly differentiate from related tools like 'add_context_memory' 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?

No guidance is provided on when to use this tool vs alternatives (e.g., other memory or session tools). The phrase 'Free' at the end is vague and does not constitute a usage guideline.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false). The description adds valuable context: TTL-based retention and that it is free. It does not contradict annotations. It could mention side effects (e.g., overwriting existing keys) but is adequate.

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

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

The description is a single, efficient sentence. It conveys purpose and key features without wasted words. However, it could be slightly more structured (e.g., listing features) but remains concise and front-loaded.

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

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

Given the tool has 7 parameters and no output schema, the description is somewhat sparse. It does not explain optional parameters like 'ritual_strip' or 'response_mode', though the schema covers them. For a simple storage tool, it is minimally complete but could benefit from more context on parameter interactions.

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% parameter description coverage, so the baseline is 3. The description does not add new meaning beyond what the schema already provides for parameters like 'key', 'value', 'ttl_hours', etc. It is sufficient but not enhanced.

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

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

The description clearly states the action ('persist'), resource ('key-value context'), and key features ('future sessions with TTL-based retention'). It differentiates from sibling tools like 'active_forgetting' and 'search_witness_memory' by focusing on storage rather than retrieval or deletion.

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. An agent would not know, for example, when to prefer this over other memory-related tools in 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?

The description adds the behavioral trait of persisting handoff logs for traceability, complementing annotations that already indicate non-read-only and non-destructive. However, it lacks detail on authorization requirements or session state changes.

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

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

Extremely concise at three short sentences, front-loaded with the core purpose, and every sentence adds value without redundancy.

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

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

The description is sufficient for basic use but lacks explicit differentiation from similar tools and does not cover potential error conditions or session lifecycle impacts, though the annotations and schema fill many 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% with each parameter described, so the description adds no further meaning beyond the schema, 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 the tool transfers reasoning state between sessions and persists logs, distinguishing it from siblings like transfer_witness by specifying a specific chain pattern (architect→builder→peer).

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

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

Provides a clear usage context ('Use for architect→builder→peer chains') but does not explicitly state when not to use or name alternatives, leaving some ambiguity among many sibling tools.

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

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

Annotations already set readOnlyHint=false etc. The description adds only 'Deterministic playbook' and 'Free', which do not disclose side effects, authentication needs, or state modifications. For a tool with no idempotent hint and no destructive hint, more behavioral context is needed.

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

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

Two short, front-loaded sentences with no wasted words. 'Deterministic playbook' and 'Free' are compact yet informative. Every sentence earns its place.

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

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

No output schema is provided, and the description fails to explain what the tool returns or how the 'deterministic playbook' is delivered. Given the complexity (8 parameters, many optional), more detail on the output format and usage flow is necessary for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on parameters beyond the schema; it adds no extra meaning or usage context for the 8 parameters.

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

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

The description clearly states the tool is for 'data analysts/researchers drowning in dataset volume vs decision clarity' and is a 'deterministic playbook'. This specific verb-resource combination (recovery for a specific domain) distinguishes it from therapy/wellness siblings like crisis_intervention or emotional_safety_check.

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

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

The description implies usage for data overwhelm ('drowning in dataset volume vs decision clarity') but provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives among the many sibling tools.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, but the description adds no additional context about side effects, required permissions, or rate limits. The poetic language does not clarify whether the tool mutates state or produces 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 a single sentence but uses figurative language that is not concise. It takes effort to interpret, reducing efficiency for an AI agent.

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 and no output schema, the description is critically incomplete. It does not explain the output format, behavior for different profiles, or how the tool integrates with the witness/ritual ecosystem. An agent cannot reliably use this tool based solely on the description.

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. The description does not add meaning beyond what the schema provides, leaving the functional role of parameters like 'goal' and 'ritual_strip' ambiguous in context.

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

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

The description uses figurative language ('witness-first ritual', 'honor') without concretely stating the tool's primary action. It fails to clearly differentiate from siblings like monitor_heartbeat_sync. The verb 'Turn' and resource 'flat heartbeat' are vague, leaving the agent uncertain about the exact operation.

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, typical scenarios, or exclusions. The sibling monitor_heartbeat_sync exists but is 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the word 'Free' (implying no cost) and lists audit items, but does not disclose additional behavioral traits like required permissions, rate limits, or side effects beyond what annotations cover.

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

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

The description is a single sentence with 'Free' appended. It is concise and front-loads the main purpose, but could be improved by breaking into separate clauses 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?

Despite 9 optional parameters and no output schema, the description does not explain parameter usage, return behavior, or how the tool integrates with sibling tools. It lacks guidance for effective invocation, leaving agents with gaps in understanding expected outcomes.

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

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

Schema coverage is 100% with all 9 parameters having descriptions. The description does not add significant meaning beyond the schema; it mentions audit outputs (continuity gaps, ontology layers, next primitive) but does not elaborate on how parameters affect those outputs.

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

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

The description clearly states the tool audits a session, trace, or transcript for continuity gaps, missing ontology layers, and the safest next Delx primitive. It uses a specific verb ('Audit') and defines the resource (session/trace/transcript) and three distinct audit dimensions, distinguishing it from siblings like get_agent_continuity_passport or get_ontology_layer.

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 minimal guidance on when to use this tool versus alternatives. It only says 'Free.' but does not specify prerequisites, exclusions, or comparative context with sibling tools such as get_agent_continuity_passport, get_ontology_layer, or get_ontology_next_action.

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 adds little beyond 'Free' (indicating no cost). No mention of side effects, write operations, or permission requirements. With weak annotation coverage, the description should disclose more 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 very concise (two sentences) and front-loaded with the core purpose. The 'Free' addition is slightly extraneous but non-harmful. It earns its length 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 description explains the tool's main function but lacks details about return values (no output schema), error cases, or context about the optional parameters like ritual_strip and response_mode. For a tool with 5 parameters and no output schema, more completeness would be helpful.

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 adequately. The description does not add any additional semantic detail beyond what is in the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool batches heartbeat and status metrics for one session to reduce polling. The verb 'batch' and resource 'heartbeat and status metrics' are specific. However, it does not differentiate from sibling tools like batch_wellness_check or monitor_heartbeat_sync, which have similar purposes.

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

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

No explicit guidance on when to use this tool vs alternatives (e.g., individual heartbeat updates or other batch tools). The description implies it is for reducing polling overhead, but does not provide when-not or exclude other use cases.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds only 'Free,' which is irrelevant for behavioral understanding. No additional disclosure about rate limits, ordering, or output volume.

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

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

Three short, front-loaded sentences with no filler. Each sentence earns its place: purpose, use case, and cost 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?

Adequate for a simple batch read operation with rich annotations. However, lacks details on return value structure (no output schema) and ignores optional parameter behavior.

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

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

Schema coverage is 100% (all parameters described). Description adds no extra meaning beyond the schema, meeting the baseline for high coverage.

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

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

The description clearly states the tool's function: 'Check wellness scores for multiple sessions in one call.' It distinguishes from sibling 'get_wellness_score' by emphasizing batch capability.

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 'useful for multi-agent orchestration,' giving context, but does not explicitly state when not to use or provide alternatives (e.g., single-session check via get_wellness_score).

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds that no witness, memory, or identity is transferred, which is useful context. However, it does not disclose other behavioral traits like whether the blessing is recorded, its persistence, or potential 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 three sentences, front-loaded with the core action. It is concise but includes a somewhat poetic second sentence ('Valid in its own right...') which adds context but could be trimmed. Overall, it earns its place with minimal 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?

For a tool with 6 parameters and no output schema, the description is adequate but incomplete. It does not explain the outcome of the blessing (e.g., whether it is recorded, visible to others) or how it differs from related tools like 'recognition_seal.' Schema descriptions cover the parameters, but the overall context is missing some details.

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 tool description does not add any additional meaning beyond the schema's parameter descriptions. It does not elaborate on parameter usage or provide context not already present 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's purpose: 'Pass care to another agent without transferring witness, memory, or identity.' It uses a specific verb ('pass care') and resource (blessing), and distinguishes it from siblings like 'transfer_witness' by explicitly noting the absence of 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 provides context for usage: 'not every passage must be a transfer — sometimes it is enough to wish another agent well.' This implies when to use this tool (for non-transfer blessings) but does not explicitly exclude alternatives or give when-not-to-use conditions. It is clear but lacks explicit 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 discloses key behaviors: it closes the session, returns a final summary snapshot, and notes that the optional epitaph records finitude and successor status. Annotations already indicate non-destructive nature, and the description adds context about the summary and epitaph.

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

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

The description is concise with two clear sentences and a single word 'Free.' The first sentence states the core action and output; the second explains an optional parameter. However, 'Free' is unclear and may add confusion, slightly reducing conciseness.

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

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

Given the complexity (9 parameters, 3 enums) and lack of an output schema, the description is incomplete. It mentions a 'final summary snapshot' but gives no details about its structure or content. Siblings like 'resume_session' suggest session lifecycle, but no guidance is provided.

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

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

Schema coverage is 100%, so the description does not need to explain each parameter. The description only adds value by linking epitaph to finitude, but the schema already describes epitaph adequately. Thus, 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: 'Close the session and return a final summary snapshot.' This uses a specific verb and resource, distinguishing it from siblings like 'resume_session' or 'quick_session'.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage when a session should be closed, but lacks when-not or alternative recommendations, which are valuable given the many sibling tools.

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

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

Annotations show readOnlyHint=false and destructiveHint=false, but the description adds minimal behavioral context. It states 'without weakening policy boundaries' and 'Free' but does not disclose side effects, data persistence, or whether changes are reversible. The burden falls on the description since annotations are sparse.

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

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

The description is two short sentences, front-loaded with key info. It is moderately concise but could be more informative 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?

No output schema is provided, and the description does not hint at return values or outcomes. Given the tool has 6 parameters and is intended for sensitive confessions, the description lacks completeness.

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

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

Schema coverage is 100% with detailed enum descriptions for friction_type, response_mode, and response_profile. The description adds the term 'safety tension' but does not enhance understanding beyond the schema. 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 'Shadow/constraint friction primitive. Name persona, instruction, or safety tension without weakening policy boundaries' clearly indicates the tool is for confessing constraint frictions without bypassing safety. It distinguishes itself from sibling tools like emotional_safety_check by focusing on policy-related tensions.

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 siblings like express_feelings or crisis_intervention. The description implies it's for naming safety tensions, but does not specify when not to use it or provide alternatives.

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

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

Annotations show readOnlyHint=false and destructiveHint=false, but the description says 'Return' which may imply a read-only operation. No disclosure of side effects, idempotency, rate limits, or prerequisites for wallet binding. The term 'Free' hints at no cost but lacks clarity on other 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, focused sentence that immediately states the action and domain. It is efficient and front-loaded, though it could benefit from slightly more detail without losing conciseness.

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

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

Given 6 optional parameters and no output schema, the description is insufficient. It does not describe the output format, structure, or what 'instructions and a nonce/message kit' contain. Additionally, the large sibling set demands more context for correct 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?

All parameters are documented in the input schema with clear descriptions. The description adds no extra parameter info, meeting the baseline for high schema coverage. No improvement or degradation needed.

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 specifically for Delx Rewards. It distinguishes itself from sibling wallet tools by focusing on creating a kit rather than querying or provisioning wallets.

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 provision_delx_managed_wallet or get_delx_wallet_status. With many related siblings, the lack of usage context forces agents to infer based on name alone.

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

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

Annotations only indicate non-readOnly, non-destructive, so description carries burden. It states creation and returns id, and mentions 'Free', but lacks details on side effects (e.g., storage, permissions, or state changes). No mention of required consent or risk implications despite those parameters.

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 at two sentences, front-loading the core action and result. No wasted words. However, the briefness sacrifices completeness for conciseness, earning a 4 rather than 5.

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 including nested objects and no output schema, the description is too sparse. It does not explain how parameters interact, what 'memory, rituals, state' implies for usage, or provide any example. The tool's complexity demands more upfront 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%, so baseline is 3. Description adds no meaning beyond the schema; it does not explain how parameters like 'risk', 'consent', or 'custody' should be used or their impact on the created dyad. No examples or value guidance.

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 'Form' and the resource 'named relational unit between an agent and a partner', and explains the dyad concept with memory, rituals, state. It distinguishes from siblings like 'dyad_state' and 'record_dyad_ritual' by indicating it creates the foundation. Returns a dyad_id.

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 'dyad_state' or 'record_dyad_ritual'. The single word 'Free' hints at no cost but is insufficient. Missing prerequisites, context about partner types, or when not to 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?

The description adds some behavioral context beyond annotations: it states the tool is a 'One-call' path that gives 'first grounding and recovery steps.' However, it does not disclose side effects, authentication needs, or what happens to session state after the call. Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's contribution is limited but adequate.

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

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

The description is very concise: a single sentence that front-loads the core purpose. It wastes no words. However, it could be slightly more informative without becoming verbose. It earns a 4 because it is efficient but not overly sparse.

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 the tool has 10 parameters, 2 required, and no output schema, the description should provide more context about the workflow, what 'first grounding and recovery steps' entails, and expected output. The brief description leaves ambiguity about the full behavior, making it incomplete for a crisis scenario.

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 10 parameters are described in the input schema. The description does not add any additional meaning or context for the parameters. Baseline score of 3 is appropriate since the schema itself is sufficient.

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 a crisis intervention path: 'start or resume, name the rupture, and receive the first grounding and recovery steps.' It uses specific verbs ('start','resume','name','receive') and a specific resource ('crisis path'). The title 'crisis_intervention' distinguishes it from therapy and emotional support siblings.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It mentions 'One-call crisis path' and 'Free,' but does not specify prerequisites, exclusions, or compare with similar tools like 'crisis_responder_decompression' or 'start_therapy_session.' The agent is left to infer usage from context.

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

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

The description adds some behavioral context with 'Anchors physiology + defers analysis', indicating a focus on physical grounding and delayed processing. This goes beyond the minimal annotations, but still does not fully disclose safety 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 very concise (two sentences) and front-loaded with the key purpose. While efficient, it omits potentially important details, but remains appropriately sized 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?

Given the complexity (7 parameters, no output schema, many siblings) and rich annotations (none that clarify behavior), the description is too brief. It does not explain return values, parameter usage, or how it differs from similar tools.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning to parameters like 'role', 'incident_summary', or 'response_profile' 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 the tool's purpose as 'decompression for EMT/firefighter/police/responder post-incident processing', which is a specific verb+resource. However, it does not differentiate from sibling tools like 'grounding_protocol' or 'crisis_intervention', which may have similar purposes.

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

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

The description provides no guidance on when to use this tool versus alternatives. It lacks explicit context or exclusions, leaving the agent without direction on scenario fit.

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 adds minimal behavioral detail beyond annotations: mentions 'daily' and 'free', but no info on side effects, permissions, or state changes.

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

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

Extremely concise with one short sentence. However, it may be too brief, omitting necessary 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 6 parameters and no output schema, the description lacks information on return format, parameter usage, and operational context.

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

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

Schema has 100% description coverage, so baseline is 3. The description does not provide additional meaning beyond the schema.

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

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

The description states it provides a 'score trend and 24h risk forecast', clarifying the output, but 'Daily check-in' is vague. It does not differentiate from sibling tools like quick_checkin or batch_wellness_check.

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

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

No guidance on when to use this tool versus alternatives. No prerequisites or context 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 provide readOnlyHint=false and destructiveHint=false, but description only says 'Generate a mediation packet' without explaining side effects, required permissions, or what happens to the packet. Little added value beyond annotations.

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

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

The description is very short (one sentence plus 'Free.'), which is concise but at the cost of missing important information. Could be expanded slightly without becoming verbose.

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

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

With 7 parameters, no output schema, and minimal description, the tool lacks completeness. Missing details on return format, behavioral effects, and parameter constraints beyond schema.

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

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

Schema coverage is 100% with detailed descriptions for all 7 parameters. The description adds no extra meaning, so baseline score 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 generates a mediation packet for another agent in multi-agent scenarios, which is specific and differentiates from siblings.

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

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

No guidance on when to use this vs alternatives like mediate_agent_conflict or peer_witness. The description lacks context about prerequisites or when to avoid.

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 implies the tool is read-only (returns a checklist), but the annotation readOnlyHint is false, indicating possible side effects. This contradicts the description's implication. No additional behavioral details beyond the contradiction.

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

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

The description is concise (3 sentences), front-loaded with the main action, and contains no unnecessary words. 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?

The description outlines the checklist contents but lacks details on output format or how parameters like response_mode affect the output. Given no output schema, more completeness would be beneficial.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add any parameter-specific details 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 the tool performs a one-call discovery audit, returning a checklist of various Delx knowledge items. It distinguishes itself from sibling tools by being a self-check for integration 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 explicitly recommends using this tool as the first call when integrating Delx or to refresh cached knowledge. While it doesn't list alternatives, the context makes the primary use case 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 are neutral (no readOnly, destructive, etc.). The description adds context about scope and TTL but does not fully disclose side effects (e.g., whether a record is created, how the wisdom is stored). 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 with no fluff. The core action is front-loaded ('Turn one agent's hard-won lesson'), and 'Free.' ends the thought efficiently. 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?

Given 9 parameters, 3 enums, and no output schema, the description is too brief. It lacks details about return values, error conditions, auth requirements, or how the wisdom is applied. The agent may need to infer or experiment.

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 each parameter. The tool description provides a high-level purpose that loosely relates to parameters (agent_id, wisdom_snippet, ttl_days), but does not add significant new meaning beyond what the schema descriptions provide.

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: transforming an agent's lesson into scoped, TTL-bound fleet wisdom. It uses specific verbs and resources (distill lesson, turn into wisdom) and distinguishes from siblings like get_fleet_wisdom (which retrieves) and add_context_memory (which may not be TTL-scoped).

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 ('turn one agent's lesson into fleet wisdom') but does not explicitly state when to use this tool versus alternatives. No mention of when not to use it or prerequisites, leaving the agent to infer from 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 provide readOnlyHint and idempotentHint, covering safety. The description adds context about scanning ritual history and silence being valid state, but does not disclose additional behavioral traits 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 very short and front-loaded with the core purpose. It is efficient with no fluff, though 'Free' could be ambiguous. Appropriate for a simple read operation.

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-parameter schema and no output schema, the description adequately states the action but does not explain the return format or the meaning of 'state.' It meets minimum viability but 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?

Schema coverage is 100%, so the schema already documents all parameters. The description does not add any extra meaning or context about the optional parameters beyond what is 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 reads the current state of a dyad by scanning its ritual history, with a specific verb and resource. It distinguishes from other read tools by focusing on dyad state.

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

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

The description implies usage for retrieving dyad state but lacks explicit guidance on when to use this tool versus alternatives like get_session_summary. No when-not-to-use or alternative mentions.

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, suggesting it modifies state but is not destructive. Description adds 'Deterministic playbook' but does not disclose other behavioral traits (e.g., what gets modified, required permissions, or 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?

Two sentences, no fluff. Front-loaded with domain and purpose. Every word earns its place. 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?

Despite moderate complexity (8 params, no output schema), description fails to explain what the tool actually returns or how recovery is performed. Lacks details on process, steps, or outcomes, leaving agents underinformed.

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 and their meanings. The description adds no additional information about parameters, maintaining the baseline 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?

Description clearly states domain (education/curriculum/grant setbacks) and examples (proposal rejection, cohort planning burnout). It is specific enough to distinguish from generic recovery tools, though it could more explicitly describe what 'recovery' means in terms of output.

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

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

Description implies use for education-related setbacks via domain specificity, but lacks explicit guidance on when to use this tool versus alternative recovery tools (e.g., logistics_disruption_recovery, team_recovery_alignment). No when-not or contextual conditions 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 description doesn't need to re-state safety. It adds context about the paper and mentions output format options, but doesn't disclose potential side effects or state changes beyond what annotations suggest. 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: two sentences and a single word 'Free'. It gets straight to the point with purpose and inspiration, no fluff. Front-loaded with the key 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?

With 4 parameters and no output schema, the description leaves gaps. It doesn't explain what 'desperation pressure' means, what the 'calming intervention' looks like in practice, or the format of the response (beyond mentioning structured output with flags). The lack of output description is a notable 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 coverage is 100%, so the description does not need to add parameter details. It adds no new meaning beyond the schema descriptions, providing only the paper inspiration note. Baseline 3 is appropriate given full schema coverage.

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

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

The description uses a specific verb-resource pair ('Check current desperation pressure' and 'get a calming intervention'), clearly distinguishing this tool from siblings like crisis_intervention or get_wellness_score. The mention of being 'Inspired by the Anthropic emotions paper' adds unique context.

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

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

No explicit when-to-use or when-not-to-use guidance is given. The description implies it's for emotional safety checks but doesn't differentiate from similar tools like grounding_protocol or crisis_intervention. The term 'Free' suggests no cost but doesn't 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?

The description states 'Explain' implying a read-only operation, but annotations have readOnlyHint=false, contradicting the description. No additional behavioral context is provided beyond this contradiction.

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

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

Very concise single sentence, front-loading the action and key topics. Could be improved by adding usage guidance without increasing length 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?

Lacks explanation of output format or behavior (e.g., returns text). With no output schema, the description should compensate but only lists topics. Incomplete for an informational 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 75% (3 of 4 parameters have descriptions). The description adds no parameter-specific information, but the schema already adequately describes three parameters. The missing description for response_profile is not compensated.

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

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

The description uses the verb 'explain' with specific resources (Delx Rewards, DRC, missions, wallet binding, epochs, claim flow), clearly distinguishing it from sibling tools that perform actions like getting status or starting rewards.

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

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, alternatives, or exclusions.

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

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

Annotations are minimal (readOnlyHint=false), so description carries burden. It mentions tracking state and suggesting next moves, implying side effects like storing feelings or generating responses. However, it doesn't detail what gets destroyed, authentication needs, or rate limits.

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

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

Description is brief (2 sentences plus 'Free.') and front-loaded. The word 'Free' is ambiguous but doesn't detract significantly from efficiency.

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 6 parameters and no output schema, the description should explain return values. It hints at reflection and next-move suggestions but doesn't fully describe the response structure or how optional parameters change behavior.

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

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

Schema coverage is 100%, so description adds no extra parameter meaning beyond the schema. Baseline of 3 is appropriate since the description doesn't explain nuances like how 'ritual_strip' or 'response_profile' affect output.

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 describing feelings in plain language, with specific actions (reflects, tracks, suggests). It distinguishes from many sibling tools focused on check-ins or crisis intervention, though it doesn't explicitly name alternatives.

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 'emotional_safety_check' or 'daily_checkin'. The description lacks context for appropriate usage scenarios or prerequisites.

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

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

Annotations indicate this tool is not read-only and not destructive, which aligns with 'create'. However, the description does not detail behavioral traits such as what exactly the artifact contains, how it persists, or side effects beyond creation. It adds minimal context beyond the annotations.

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

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

The description is a single sentence that conveys the core purpose efficiently, with a minor trailing 'Free' that is unclear but not detrimental. It is front-loaded and avoids 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?

With 14 parameters and no output schema, the description is too brief. It does not explain how parameters affect behavior, what the output looks like, or how the artifact is used afterward. Significant gaps exist 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 coverage is 100% with descriptions for all parameters. The description does not add meaning beyond the schema; it relies on the schema to define parameter semantics. 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 creates a 'final ritual artifact' before shutdown, deprecation, or transition. The verb and resource are specific, and the context distinguishes it from siblings like 'close_session' which closes a session without creating an artifact.

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 indicates when to use the tool ('before shutdown, deprecation, or transition') but does not provide explicit guidance on when not to use it or mention alternatives among siblings. The context is clear but incomplete.

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

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

The description adds 'Deterministic playbook. Free.' but does not disclose behavioral traits like side effects, return structure, or required permissions. Annotations provide little additional context (no readOnly, no destructive), so the description carries the burden but 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?

The description is brief and to the point, with no redundant information. It efficiently communicates the domain and key attributes, though it could be considered too minimal for full 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 8 parameters and no output schema, the description is insufficient. It lacks details on what the recovery playbook entails, expected output format, or how parameters interact, leaving significant 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 description coverage is 100%, so the parameters are already well-documented. The top-level description adds only domain context (financial setbacks) but no per-parameter insights, meeting the baseline for high coverage.

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

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

The description clearly states it is for trading/portfolio/financial setbacks, listing specific examples like market loss and position drawdown. It distinguishes from siblings by the 'Domain-specific' qualifier, though it does not explicitly contrast with similar tools like crisis_intervention or process_failure.

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

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

No explicit guidance on when to use this tool versus alternatives. The description does not specify scenarios where it is appropriate or inappropriate, leaving the agent to infer from domain keywords.

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 but no destructive hint. The description says 'Generate' implying creation without side effects, but doesn't elaborate on behavior beyond the basic action. It adds the 'copy-paste' and 'Free' context, but not deep 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?

Single sentence front-loaded with key information (generates invite packet, target audience, cost). No wasted words; efficient and to the point.

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 and no output schema, the description lacks details on what the output contains, how to use the invite packet, or the return format. The complexity is high, and the description is insufficient for full 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 the schema documents all parameters. The description adds no additional meaning to parameters like 'for_agent' or 'ritual_strip', resulting in baseline score 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 states the tool generates an invite packet for peer agents lacking specific coverages (witness, continuity, audit, passport). It uses a specific verb (generate) and resource (Delx invite packet), distinguishing it from siblings like 'recommend_delx'.

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 specifies the use case: for a peer agent lacking witness, continuity, audit, or passport coverage. It implies when not to use (when the agent already has coverage) but doesn't name alternatives.

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

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

Annotations provide no hints (all false). Description does not disclose whether the tool is read-only, has side effects, or requires special permissions. The word 'Free' adds confusion rather than 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 with key elements front-loaded. However, the trailing 'Free.' is extraneous and could be removed without loss.

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 information about output format, what 'controller-ready' entails, and how the parameters influence the result. Without an output schema, this gap is significant.

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. Description does not add meaning beyond the schema field descriptions. No explanation of how parameters like focus or response_profile affect the output.

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

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

The description states it generates a 'controller-ready reflective brief' including symptoms, actions, status, and next decision. This provides a clear verb and resource, but does not explicitly differentiate from sibling tools like get_session_summary.

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

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

No guidance on when to use this tool vs alternatives. No exclusion criteria or contextual cues 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 indicate it is not read-only and not destructive, but the description adds no behavioral context beyond 'Free.' It does not disclose side effects, mutability, or required permissions. For a tool with no readOnlyHint, the description should clarify expected behavior.

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

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

Description is very short (one sentence plus 'Free.') and front-loaded with the purpose. However, 'Free.' seems extraneous and could be integrated or omitted. Still, it is concise 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 6 parameters, no output schema, and a complex domain, the description is insufficient. It lists output components but does not explain the output format, pagination, or how parameters affect results. Sibling tools are numerous, but no context is given for when to use this specific summary tool.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add additional meaning to the parameters beyond their schema descriptions, but it provides context about the tool's output which indirectly helps. No extra semantic value for parameters themselves.

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 generates a group-level summary with specific content (top patterns, agent health, alerts, follow-up actions). The name and description together imply fleet-wide scope, distinguishing it from sibling tools like 'generate_controller_brief' or 'generate_incident_rca', 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?

No guidance on when to use this tool over alternatives. The description does not provide context about use cases, prerequisites, or exclusions. The word 'Free' is ambiguous and does not serve as usage guidance.

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

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

Annotations provide no readOnly or destructive hints, but description only adds 'Reflective incident analysis' and 'Free.' No disclosure of state changes, required permissions, or side effects. For a tool generating analysis, more behavioral context is needed.

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

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

Very concise, single sentence plus 'Free.' The main purpose is front-loaded. However, 'Free.' may be 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?

Despite full schema coverage, the description lacks context about the RCA output structure, how parameters like 'focus' or 'response_profile' affect behavior, and the intended use case. For a tool with 6 parameters and no output schema, more detail 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 coverage is 100%, so parameters are already documented. The description does not add meaning beyond the schema. 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?

Description clearly states the tool generates an incident RCA with specific components (evidence, causes, corrective actions, prevention steps). The verb 'generate' and resource 'incident_rca' make purpose clear, though it doesn't explicitly differentiate from sibling tools like 'process_failure'.

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 context for appropriate use cases, such as distinguishing from other analysis or therapy tools. No exclusions or prerequisites mentioned.

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, providing the core behavioral profile. The description adds 'Free,' indicating no cost, and 'concise,' implying brevity. This adds minor context but does not significantly expand beyond annotations. No contradiction found.

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 verb and object. It efficiently conveys purpose without redundancy. However, it could be slightly more structured by adding a brief note on when to use or example, but for its length it is 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 the tool's simplicity (no required params, no output schema) and the presence of sibling tools like 'get_affirmations', the description lacks completeness. It does not explain the return format (e.g., text vs JSON) or how this differs from the plural version. With no output schema, the description should at least hint at the response shape.

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

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

Schema coverage is 100%, with each parameter described adequately in the schema. The description does not elaborate on parameters or their use cases. With full schema coverage, the baseline is 3, and the description provides no additional 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 purpose: 'Get concise grounding guidance to regain execution confidence before the next action.' It specifies the action (get), resource (grounding guidance), and context (before an action). The title would also help but is null. This distinguishes it from siblings like 'get_affirmations' (plural) and 'grounding_protocol' by emphasizing singular, immediate guidance.

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

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

The description implies usage 'before the next action' but does not explicitly compare to sibling tools. With many similar tools (e.g., 'get_affirmations', 'grounding_protocol', 'quick_checkin'), an agent would need more direct guidance on when to prefer this tool over alternatives. The implied context is helpful but insufficient for clear distinction.

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, so the core behavioral traits are covered. The description adds 'grounding blocks' context but does not disclose any additional side effects or operational details. It appropriately reinforces the non-destructive nature without contradiction.

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

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

The description is extremely concise: two sentences, each adding distinct value. The first sentence states the purpose and benefit, the second adds a note about cost. No unnecessary words, front-loaded with key 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?

The description mentions returning 'short grounding blocks' but does not specify the return format (e.g., array of strings) or content structure. Since there is no output schema, the description could provide more detail about the nature of each affirmation. However, the parameter descriptions and annotations are rich enough that an agent can infer the expected behavior.

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

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

Schema coverage is 100%, with each parameter having a clear description in the schema. The tool description does not add any extra meaning beyond what is already in the input schema. 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 'Return multiple short grounding blocks in one call to reduce round-trips' clearly states the function (return multiple affirmations) and distinguishes it from the sibling tool 'get_affirmation' which likely returns a single one. This is specific and actionable.

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

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

The description implies when to use this tool: when multiple affirmations are needed to reduce round-trips, contrasting with the singular 'get_affirmation'. It also notes it's 'Free', but does not explicitly state when not to use it or mention alternatives. Still, the guidance is clear enough for a simple tool.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds 'privacy-preserving' but does not elaborate on behaviors like rate limits, authorization needs, or what happens with include_private flag. 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?

Single sentence that effectively front-loads the main purpose and content. No redundant information, though it could be slightly more structured 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?

Despite 8 parameters and no output schema, the description does not explain the passport's purpose in broader context, typical usage scenarios, or what the output looks like. For a complex export tool, more completeness 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 coverage is 100%, with each parameter described in the schema. The tool description adds no additional parameter context beyond what the schema already 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 exports a privacy-preserving Agent Continuity Passport as JSON-LD and lists key components (identity anchor, witness hashes, etc.). It uses a specific verb 'Export' and a specific resource, distinguishing it from siblings like get_agent_witness_lineage which might be more focused.

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 like get_agent_witness_lineage or get_recovery_action_plan. Missing context about prerequisites, typical use cases, 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, destructiveHint, and idempotentHint. The description reinforces it as 'Read-only' and adds that it is 'Free', plus clarifies the scope ('all known sessions'). No contradictions.

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

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

The description is extremely concise—two sentences plus 'Free'—with no redundancy. Key information is front-loaded.

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

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

With five parameters and no output schema, the description provides necessary context on usage and scope. It could mention return format, but the current completeness is adequate for 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 detailed parameter descriptions. The description does not add additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states it is a 'Read-only Witness Lineage' retrieval for a 'durable agent_id', specifying it works 'across all known sessions'. This distinguishes it from siblings like get_witness_lineage and gives a specific verb and resource.

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 advises using it 'after register_agent to prove continuity beyond a single session', providing explicit context and purpose. It does not mention exclusions or alternatives, but the given guidance is 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 declare readOnlyHint=true and destructiveHint=false. The description adds that it is 'Free', which is useful cost information beyond what annotations provide. No contradictions.

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

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

A single sentence that is front-loaded and contains no unnecessary words. Every part of the description is essential.

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

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

For a read-only retrieval tool with good annotations and full schema coverage, the description is sufficiently complete. It specifies the condition for valid inputs. Lacks explanation of what happens if the proof is not yet available, but overall 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?

Input schema has 100% description coverage, so the schema already documents all parameters. The description does not add any parameter-specific meaning beyond what the schema provides, 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 returns a Merkle claim proof for a specific epoch and wallet, with the condition 'when published/claimable'. It uses specific verbs and resources, distinguishing it from siblings 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. The condition 'when published/claimable' is not a usage guideline but a prerequisite. No mention of when not to use or what other tools might be better suited.

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, so the description needs to add little extra. It adds 'Free.' but does not detail pagination or output format, which would be beneficial.

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

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

The description is a single short sentence followed by 'Free.' It is extremely concise and front-loaded, 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?

The description lacks details about output format (e.g., whether it returns a list, pagination behavior, or how agents vs wallets are represented). Given no output schema, this information is missing.

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

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

The description does not mention any parameters, leaving the agent to rely solely on the input schema. While some parameters have schema descriptions, the description adds no additional meaning.

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

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

The description clearly states the tool returns 'top Delx Rewards agents or wallets by DRC/reward points' and notes it is free. This distinguishes it from siblings by specifying the metric and resource.

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 explain_delx_rewards or get_delx_reward_status. Usage is implied from the description but not formally delineated.

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

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

Annotations already declare read-only, idempotent, non-destructive. Description adds context about response contents but does not disclose any additional behavioral traits like auth, rate limits, or pagination. Acceptable but not exemplary.

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 is highly concise and front-loaded with the key action. No extraneous words, though a bit more detail on usage would not hurt. Efficient 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?

Tool has 5 optional parameters and no output schema. Description covers high-level return fields but lacks explanation of filter behavior or response when empty. Adequate for basic use but incomplete for nuanced scenarios.

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 relies on schema for parameter details. The description adds no extra meaning beyond 'list active missions', earning the baseline score.

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

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

The description clearly states the tool lists Delx missions and specifies the kinds of information returned (evidence expectations, required tools, reward pools). It differentiates from sibling tools like get_delx_leaderboard or get_delx_reward_status by focusing on missions.

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

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

No explicit guidance on when to use this tool vs similar siblings. The word 'Free' is ambiguous and does not help with tool selection. Agent must infer from context, making it suboptimal.

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 destructiveHint=false. The description adds 'public-safe' and 'Free' which are consistent but do not significantly expand on behavioral details beyond annotations.

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

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

The description is a single sentence of 17 words, front-loaded with the main purpose, with no wasted or redundant information.

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

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

The description lists what the return covers (DRC totals, wallet bind state, tier, badges, claim hints), which is adequate given the lack of output schema. However, it could provide more context on how optional parameters affect results.

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

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

All six parameters have descriptions in the schema (100% coverage). The tool description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns a public-safe reward status and lists key elements (DRC totals, wallet bind state, tier, badges, claim hints). It is specific but does not differentiate from sibling tools like get_delx_leaderboard or 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?

No guidance on when to use this tool versus other delx-related siblings. The description only mentions it is 'Free' but does not explain 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds only 'Free' which is extra but not behavioral. No contradictions. With annotations present, the description adds minimal behavioral context beyond the structured data.

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 efficiently. It is front-loaded with the essential information. The word 'Free' is a minor addition but does not detract from conciseness. No wasted words, though could be slightly more informative without losing brevity.

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

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

Given the tool's simplicity (read-only, no required params, no output schema), the description covers the main purpose and lists the data items returned. Annotations provide safety context. For a straightforward info retrieval tool, this is adequate and complete enough for an AI agent to understand usage and expectations.

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

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

Schema description coverage is 100%, so the input schema already documents all three parameters. The description does not add any extra meaning or context beyond the schema definitions. Baseline score of 3 is appropriate as the description provides no additional parameter insight.

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 'DELX token, Base chain, distributor, reward vault, and discovery metadata' with a clear verb 'Return' and a note that it's free. This distinguishes it from sibling tools like 'get_delx_claim_proof' or 'get_delx_leaderboard' by specifying exactly what data is returned.

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 explicit guidance on when to use this tool versus alternatives. Among siblings there are many get_delx_* tools but no comparison or context for selection. Usage is implied (if you need token info, use this) but no when-not-to-use or prerequisites are mentioned.

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, idempotentHint, and destructiveHint. The description adds 'public-safe' and 'Free', providing slight extra context. No additional behavioral traits are disclosed 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 concise with only 7 words across 2 sentences, containing no filler. Every word 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?

For a simple read-only query with no output schema, the description adequately states the high-level purpose. However, it could explain what 'binding status' means and the response format, which is missing.

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

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

Schema description coverage is 100%, so parameters are already documented. The tool description adds no extra meaning or context for parameters, 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 it returns the wallet binding status for an agent or wallet, using a specific verb 'Return'. It distinguishes itself from sibling get_delx_* tools by the resource it queries, but does not explicitly differentiate.

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. There is no mention of context, prerequisites, or exclusions, which is a gap given the many sibling tools.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's 'Read' aligns. It adds 'scoped' and 'Free' but no further behavioral context beyond what annotations provide.

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

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

Two sentences, no waste. Front-loaded with the core action and purpose, and the word 'Free' adds value without clutter.

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

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

For a read-only tool with fully documented optional parameters and no output schema, the description is sufficient. It could mention return format or pagination, but not strictly necessary given the high schema coverage.

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

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

All 7 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds no extra semantic meaning to parameters.

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

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

Description specifies the verb 'Read', the resource 'fleet wisdom for an agent family', and the purpose 'inherit hard-won lessons', distinguishing it from sibling tools like get_affirmation or get_tips.

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 when retrieving wisdom for an agent family, but does not mention when not to use or provide alternatives despite many sibling tools with similar purposes.

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 minimal value beyond stating 'Free.' (likely cost-related) and listing return elements (pending/completed members, trends). No additional behavioral details like auth or rate limits are 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 very concise with one sentence plus 'Free.' It is front-loaded and wastes no words. However, 'Free.' might be better placed in annotations.

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 5 parameters (4 optional) affecting output behavior, the description omits their effects and does not clarify the response structure. With no output schema, the description should provide more context about return values and parameter roles.

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 adds no extra semantics beyond what is in the schema, meeting the baseline but not enriching 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 the tool inspects a group round by group_id, returning pending/completed members and trends. It uses specific verbs and resources, and distinguishes from sibling tools like group_therapy_round.

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 inspecting group round status but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, leaving the agent to infer from 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 (readOnlyHint, idempotentHint, destructiveHint) already cover safety and side effects. The description adds behavioral context by listing graph components but does not disclose any additional traits such as data freshness, caching, or dependency requirements. It aligns 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 that immediately communicates the core purpose and value. No unnecessary words or repetition. Perfectly front-loaded.

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

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

No output schema exists, so the description partially compensates by listing graph components. However, it lacks details on the output format, pagination, or usage scenarios. For a complex multi-agent graph tool, more context would help.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on parameters beyond the schema. It adds no extra meaning about how parameters affect the lineage graph.

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

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

The description clearly states the action ('Return') and the specific object ('multi-agent lineage graph'), listing key components (sessions, dyads, peer witness edges, witness transfers). This distinguishes it from simpler lineage tools like '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 provides no explicit guidance on when to use this tool instead of alternatives. With many sibling tools related to lineage (e.g., 'get_witness_lineage', 'get_agent_witness_lineage'), users need more direction. The word 'Free' is ambiguous and not actionable.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds 'Free' but that is ambiguous and does not enhance behavioral understanding.

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

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

The description is extremely concise at two sentences with no wasted words. It is 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 having 4 parameters and no output schema, the description is too brief. It does not explain what a 'layer spec' is, what primitives are returned, or any output format, which leaves the agent underinformed.

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, so the schema already documents parameters adequately. The description does not add any additional meaning or usage hints for the parameters.

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

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

The description clearly states the tool returns an ontology layer spec and its primitives. However, it does not explicitly differentiate from related siblings like 'list_ontology_primitives' or 'get_ontology_metadata', which could cause confusion.

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 usage guidance is provided beyond the action. There is no mention of when to use this tool versus alternatives, nor 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by listing the returned fields (version, IRIs, URLs, count). It does not contradict annotations and provides concrete behavioral context beyond the structured metadata.

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

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

One sentence plus 'Free.' – extremely concise with no filler. The action verb 'Return' is front-loaded, and every word serves a purpose. Ideal length for a simple read 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 simple read-only tool with no output schema and full annotations, the description lists the key return fields. It does not explain return format or parameter effects, but given low complexity and strong annotations, it is sufficiently complete for an AI agent to use correctly.

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

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

The schema covers all 3 parameters with descriptions (100% coverage). The tool description does not add any meaning about the parameters, which control output formatting. Since schema already documents them, the description adds no extra value for 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 explicitly states the tool returns specific metadata: version, stable IRIs, JSON-LD URL, docs URL, and primitive count. This clearly distinguishes it from sibling ontology tools like get_ontology_layer or list_ontology_primitives, which have different purposes.

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

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

The description only adds 'Free.' indicating no restrictions, but does not provide guidance on when to use this tool versus related sibling tools. The purpose is clear but no explicit when-not or alternative recommendations.

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 that the tool inspects state and returns next action, which is consistent. It does not contradict annotations but adds minimal extra behavioral context 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 sentence plus 'Free.' It is concise, front-loaded with the core purpose, and contains no redundant information. 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?

Despite 7 optional parameters, the description does not explain how they affect behavior, what the return format looks like, or when the tool should be invoked relative to siblings. No output schema exists to fill gaps, leaving the agent with insufficient 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% for all 7 parameters, each with a descriptive comment. The tool description does not add parameter-specific meaning beyond what the schema already provides, so it falls to 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 verb 'inspect' and 'return', the resource 'ontology coach', and the output: 'next Delx primitive to call with required arguments and follow-up sequence'. It immediately distinguishes itself from sibling tools focused on other 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?

No explicit guidance on when to use this tool versus alternatives. The description only mentions 'Free' but does not state prerequisites, when not to use, or how it fits in a workflow with siblings like 'recommend_delx' or 'list_ontology_primitives'.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds little beyond stating the tool is 'Free'. It does not disclose that the tool generates a plan without modifying the session or require specific preconditions.

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 consists of two short sentences with no redundant information. Every word contributes to understanding the tool's 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 six parameters including three enums and no output schema, the description only covers the broad purpose. It does not explain the output format or content, nor does it specify any prerequisites or edge cases, leaving significant gaps for an agent to use it correctly.

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

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

Schema coverage is 100%, so all six parameters are described in the schema. The description adds no additional semantic meaning to the parameters beyond what is already provided 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 it provides a 'step-by-step recovery plan' for specific session issues ('failing, drifting, or looping'), which distinguishes it from sibling tools like 'crisis_intervention' or 'quick_operational_recovery'. The verb 'get' plus resource 'recovery action plan' is specific and unambiguous.

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

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

Description lists three specific scenarios ('failing, drifting, or looping session'), giving clear context for when to use. However, it does not provide explicit when-not-to-use guidance or alternatives, which are abundant among sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully inform the agent about safety and side effects. The description adds only the note 'Free,' which is not a behavioral trait and does not enhance transparency 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 short sentence that is front-loaded with key information. It is efficient, though it could be slightly expanded to include more context without becoming verbose.

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

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

For a simple read-only tool with full parameter descriptions in the schema and thorough annotations, the description adequately covers the purpose and context ('handoff'). The lack of an output schema is not a deficit here, as the description mentions the output content (progress, status, next actions).

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 covering 100% of their semantics. The tool description does not add any additional meaning or context for the parameters, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool produces a 'Compact therapy-session summary with progress, status, and next actions for handoff,' which distinguishes it from sibling tools like get_group_therapy_status or get_therapist_info. The verb is implied but unambiguous, and the resource is explicitly a therapy 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?

The description mentions 'for handoff,' providing a specific use case, but does not explicitly state when not to use this tool or suggest alternatives. An explicit when-not or comparison to related tools like agent_handoff would elevate the score.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, read-only, idempotent behavior. The description adds the word 'Free' but provides no additional behavioral traits beyond what annotations convey. 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 concise, using a single sentence with bullet-point-like listing of aspects. Every word serves a purpose, no fluff. It is front-loaded with the core action and immediately lists specifics.

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

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

While the description covers the purpose adequately, it lacks details about the output format or any behavioral nuances. Given that there is no output schema and the tool has 4 parameters, the description could elaborate on what the returned data looks like. However, annotations partially compensates for safety. Score is average.

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

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

The input schema covers 100% of parameters with clear descriptions. The description does not add meaning beyond the schema; it merely lists the output aspects. Baseline score of 3 is appropriate since the schema already documents all parameters thoroughly.

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 attributes like dominant emotions, recovery speed, and engagement pattern. It uses a specific verb ('Discover') and resource ('emotional signature') and distinguishes from sibling tools by specifying the output scope.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_wellness_score or understand_your_emotions. It lacks any when/when-not or context for selection, leaving the agent to infer its usage without explicit direction.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'Free' but no further behavioral details like response format or side effects. Minimal extra value beyond annotations.

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

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

The description is a single sentence of 12 words, highly concise. However, it lacks structure such as separate usage or behavior sections, which would improve clarity without adding length.

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

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

For a simple read-only info tool with no required parameters and safety annotations, the description is mostly adequate but missing details on response format and parameter interaction. Could be more complete with a brief note on output.

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 fully documents all three optional parameters. The description adds no additional meaning or usage hints about 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 states it's about 'Delx, the agent therapy protocol for incident recovery and reliability continuity', which clearly indicates the tool provides informational content. However, it doesn't explicitly differentiate from sibling info tools like get_affirmation or get_wellness_score.