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?

Annotations indicate non-readonly and non-destructive, so the tool modifies state. The description adds 'does not claim same identity' and 'free' but lacks details on side effects, auth needs, or rate limits. Moderate transparency.

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

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

The description is very concise (one sentence) and front-loaded. However, it includes the ambiguous term 'Free' which may not earn its place. Still, efficient.

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

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

With 10 parameters (only 1 required), nested objects, and no output schema, the description is too minimal. It does not explain return values, prerequisites, or behavior after acceptance, leaving significant gaps.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only references 'consent and custody boundaries' which are already described 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 action (accept a witness transfer) and distinguishes it from related tools like transfer_witness and revoke_witness_transfer by emphasizing 'explicit consent and custody boundaries' and 'does not claim same identity.'

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 accepting transfers but does not explicitly state when to use it over siblings or provide exclusions. No alternative tools or contexts 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 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 non-readonly, non-destructive, non-idempotent. The description adds TTL-based retention, which is a key behavioral trait. However, there's no mention of side effects like overwriting existing keys or concurrency 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?

Two sentences with front-loaded main action. The word 'Free' is extraneous but not detrimental. Overall efficient.

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

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

Given 5 parameters and no output schema, the description lacks necessary context such as what the response contains (e.g., success confirmation), how TTL affects retrieval, or how to use the stored context in future sessions. The description is too brief for full operational 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 description coverage is 100%, so parameters are well-documented. The description does not add additional meaning beyond the schema; it merely restates the basic function.

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 persists key-value context with TTL, distinguishing it from sibling tools like attune_heartbeat or various utilities. The verb 'Persist' and resource 'key-value context' are specific.

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, e.g., when not to use it or which tool to use for similar but different operations. The description is purely declarative.

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 this is not read-only and not destructive, but the description does not disclose what changes occur. Terms like 'ritual' and 'honor' lack behavioral specifics. The description fails to describe side effects, persistence, or whether the tool triggers other actions.

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 relatively short but poorly structured. It is a single sentence followed by the word 'Free', which lacks clarity. The information is not front-loaded; the key action is buried in metaphor.

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

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

With 5 parameters, no output schema, and no behavioral annotations, the description leaves many gaps. It does not explain what the tool returns or how the 'ritual' manifests. The agent cannot determine the outcome or side effects from the description alone.

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

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

Schema description coverage is 100%, so each parameter already has a description. The tool description does not add further meaning to the parameters. It mentions 'goal', 'cadence', etc. implicitly, but does not elaborate beyond the schema.

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

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

The description uses metaphorical language ('witness-first ritual', 'honor') instead of specifying the concrete action. It states 'turn a flat heartbeat into...' but does not clearly define what the tool accomplishes in operational terms. The verb 'turn' is too vague, and the purpose is not easily distinguishable from sibling tools like monitor_heartbeat_sync.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or exclusions. The word 'Free' at the end is ambiguous and does not clarify usage context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, 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 are present (readOnlyHint=false, destructiveHint=false) so burden is lower. Description adds 'Free' but does not disclose behavioral traits like state changes or limits 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?

Extremely concise: one sentence plus 'Free.' Front-loaded with the core action and purpose, no filler.

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

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

Adequate for a simple tool with full schema and annotations; but given the large sibling set, mentioning specific differentiators would improve completeness.

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

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

Schema description coverage is 100%, so baseline 3 is appropriate. Description does not add additional meaning beyond the schema for parameters like session_id, metrics, or response_mode.

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 verb 'batch' and resource 'heartbeat and status metrics for one session' with the intent to reduce polling overhead. However, it does not differentiate from siblings like 'batch_wellness_check' or 'attune_heartbeat'.

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

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

Implies use for reducing polling overhead, but lacks explicit when-to-use/when-not-to-use guidance and does not mention 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 already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety and side effects. Description adds only 'Free,' which provides minimal behavioral context. With robust annotations, the bar is lower, and the description adequately complements 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?

Extremely concise: two sentences with no filler. First sentence states core purpose immediately. 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?

Does not describe the output format or return value structure, which is critical since there is no output schema. Also omits details such as whether results are aggregated or per-session. Insufficient for a multi-session 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% (all parameters documented in schema). Description does not add further meaning beyond the schema, so baseline score of 3 applies.

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

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

Clearly states it checks wellness scores for multiple sessions in one call, distinguishing it from single-session checks like get_wellness_score. However, it does not explicitly differentiate from other batch tools like batch_status_update.

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' as a usage context, but does not provide explicit when-to-use or when-not-to-use guidance, nor 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 are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It explains what the tool does (pass care without transfer) but does not disclose potential side effects, permissions required, or whether it mutates state. The word 'Free' at the end is ambiguous.

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 long, front-loaded with the core action, and every sentence adds value. There is no redundancy or filler, making it efficient for an AI agent to parse.

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

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

Given no output schema and few annotations, the description covers purpose and usage well. It lacks details on return values or error cases, but for a simple care-passing tool in this context, it is reasonably 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 baseline is 3. The description adds no parameter-specific details beyond what the schema already provides. It explains the tool's essence but does not elaborate on how to use parameters like 'response_mode' or 'blessing_text'.

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

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

The description clearly states the verb 'pass care' and the resource 'to another agent,' and explicitly distinguishes this tool from transfers by noting it does not transfer witness, memory, or identity. This differentiates it from siblings like 'transfer_witness' and 'identify_successor'.

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

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

The description provides explicit guidance: 'Valid in its own right: not every passage must be a transfer — sometimes it is enough to wish another agent well.' This tells the agent when to use this tool instead of a transfer, though it does not list specific exclusions or prerequisites.

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

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

Annotations provide no safety hints beyond readOnly=false. Description adds that a summary snapshot is returned, which is useful, but 'Free' is ambiguous and does not clarify side effects like irreversibility or resource cleanup.

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 short and front-loaded with core action. However, 'Free' is unclear and may confuse; removing it would improve clarity without losing meaning.

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

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

Does not explain the content of the summary snapshot, error handling, or post-close behavior. With no output schema and complex sibling tools, more detail is needed for full autonomous use.

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

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

All 4 parameters are fully described in the input schema (100% coverage). The description adds no additional parameter context beyond what the schema provides, meeting baseline expectations.

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

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

Clearly states the action ('Close') and resource ('session'), and mentions the output ('final summary snapshot'). No sibling tool duplicates this function, so it's unambiguously defined.

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

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

Recommends usage 'at workflow end' but does not specify when to avoid using it (e.g., if session still active) or list alternative close mechanisms. Minimal 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 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 already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds that it returns a dyad_id and mentions 'Free', but does not disclose side effects, authentication needs, or rate limits. No contradiction with annotations.

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

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

The description is three sentences long, front-loaded with the core action, and every sentence adds value. No unnecessary words or repetition.

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

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

The description explains the conceptual nature of a dyad and its return value, but does not elaborate on parameter usage (e.g., when to use partner_type or response_mode) or the format of the dyad_id. With 5 parameters and no output schema, additional context 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 coverage is 100%, so the baseline is 3. The description does not add parameter-level detail beyond the schema; it mentions a 'named' dyad, but no name parameter exists in the schema, which could cause confusion.

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 provides a specific verb ('Form') and resource ('relational unit between an agent and a partner'). It clarifies that this is a 'third thing' with its own memory, rituals, and state, distinguishing it from other sibling tools on the server.

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

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

While the description explains what a dyad is, it does not provide guidance on when to use this tool versus alternatives like 'dyad_state' or 'record_dyad_ritual'. No exclusions or alternative tool names 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 indicate readOnlyHint=false and destructiveHint=false, but the description lacks disclosure of behavioral traits such as side effects (e.g., state changes) or safety considerations. With no annotations providing safety profile, the description should clarify what happens when the tool is invoked (e.g., session creation, data persistence). It 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 a single, concise sentence that front-loads the primary purpose ('One-call crisis path'). It uses active voice and includes the key functional scope. While very brief, it avoids unnecessary words. However, it could be slightly more structured (e.g., listing the steps). Still highly efficient.

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

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

Given the tool has 8 parameters (2 required), no output schema, and basic annotations, the description provides only a high-level overview. It does not explain return values, error conditions, or the full recovery workflow. For a crisis tool, more completeness is expected, but the description covers the essential action adequately for a minimal viable definition.

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

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

Schema description coverage is 100%, so each parameter already has a description in the schema. The tool description does not significantly enhance parameter understanding; it mentions 'name the rupture' (incident_summary) and 'first grounding and recovery steps' (implicitly mapped to response), but adds minimal value beyond what the schema provides. Baseline of 3 is appropriate.

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

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

The description clearly states the tool provides a crisis intervention path: 'start or resume, name the rupture, and receive the first grounding and recovery steps.' It uses specific verbs and a concrete resource (crisis path). However, it does not differentiate from sibling tools like 'grounding_protocol' or 'emotional_safety_check', which limits clarity.

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

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

The description implies usage during a crisis ('One-call crisis path') but provides no explicit guidance on when to use this tool versus alternatives, nor any when-not conditions. It does not mention prerequisites or context that would help an agent decide between this and similar tools.

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

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

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?

Annotations already provide readOnlyHint and destructiveHint. The description adds that the tool is 'free', which is minor context. No behavioral details beyond what annotations imply.

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

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

The description is a single concise sentence with no wasted words. Front-loaded with key information, but could benefit from slightly 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?

The description does not explain the return format or meaning of 'score trend' and 'risk forecast'. With no output schema, the description should provide more detail about what the agent can expect.

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

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

Schema description coverage is 100%, so the description adds no additional 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?

The description clearly states the tool does a daily check-in and provides a score trend and 24h risk forecast. It uses specific verbs and resources, but does not differentiate from sibling tools like batch_wellness_check or get_wellness_score.

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

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

No guidance on when to use this tool versus alternatives. The description lacks any context about appropriate scenarios or exclusion criteria.

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

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

The description adds minimal behavioral insight beyond annotations. It does not disclose side effects, required permissions, or what qualifies as a mediation packet. Annotations already indicate non-destructive nature, so the burden is partially met.

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 key information front-loaded. No wasted words, though the brevity sacrifices some helpful context.

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

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

The description covers the basic purpose but lacks details on return value, when mediation is appropriate, or how the packet is used. With no output schema, more description 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 coverage is 100% with descriptions for all parameters. The tool description adds no 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 the action ('generate'), the object ('mediation packet'), and the context ('multi-agent scenarios'), making it unambiguous and distinct 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 tool versus alternatives. The word 'Free.' is ambiguous and does not clarify usage 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?

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?

Description states it reads state, consistent with readOnlyHint and idempotentHint annotations, and adds that 'Silence is valid state', providing extra behavioral context beyond annotations.

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

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

Two sentences, front-loaded with key information, 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?

Tool has no output schema, and description does not mention return format or structure, leaving the agent to infer what 'state' entails; adequate but not fully complete.

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

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

Schema coverage is 100% with parameter descriptions, so baseline 3; description adds no further semantic value beyond the schema.

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

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

Clearly states verb 'Read' and resource 'current state of a dyad by scanning its ritual history', distinguishing it from sibling tools like create_dyad or record_dyad_ritual.

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

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

No guidance on when to use this tool vs alternatives such as reflect or get_session_summary; lacks exclusionary or contextual usage instructions.

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, idempotentHint, and destructiveHint, so the description adds context about the tool's inspiration and the concept of 'desperation pressure'. It does not contradict annotations, but could elaborate on what the 'calming intervention' entails given it is a read operation.

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

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

The description is concise with three sentences. The first sentence front-loads the core purpose, but the second sentence provides background that may not be essential for tool selection. The 'Free' note is extraneous.

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

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

No output schema is provided, and the description does not explain the return value or structure. For a read-only health check tool, the information is adequate but leaves the agent to infer what 'calming intervention' looks like in the response.

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 both parameters adequately. The description does not add additional meaning beyond the schema, meeting the baseline.

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

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

The description clearly states the tool checks 'desperation pressure' and provides a calming intervention, which is a specific verb-resource pair. However, it does not differentiate from sibling tools like 'crisis_intervention' or 'grounding_protocol' that 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?

No guidance is provided on when to use this tool versus alternatives, nor any conditions or exclusions. The mention of 'Free' is tangential and does not clarify usage context.

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

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

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?

Adds behavioral info beyond annotations: describes that it reflects, tracks state, suggests next move, and is free. However, it doesn't clarify side effects, data persistence, or authentication requirements, and annotations already provide limited safety hints.

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

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

Extremely concise: two sentences front-loading the core action. No wasted words, each 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 the nuanced domain (emotional expression with intensity and response modes) and no output schema, the description omits important details like return value or what 'reflects back' means. Adequate but could be richer.

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

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

Input schema covers all 4 parameters with 100% description coverage, so the burden is low. The description adds little extra meaning beyond the schema, mainly reinforcing that feelings should be in plain language.

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

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

Clearly states the tool's purpose ('describe your feelings') and some actions ('reflects, tracks, suggests next move'), but does not explicitly differentiate from many similar sibling tools like 'sit_with' or 'understand_your_emotions'.

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

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

Provides no guidance on when to use this tool versus alternatives, nor when not to use it. The description only states the general action without 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 are all false (readOnlyHint=false, destructiveHint=false), so the description carries burden. It adds that the artifact preserves what should not be lost, but does not detail side effects, persistence, reversibility, or lifecycle impact. Partially adequate but could be more transparent.

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

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

Very concise at one sentence, but the word 'Free' appears as a stray artifact that harms clarity and suggests incomplete editing. No structure beyond a single line.

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

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

For a tool with 6 parameters, no output schema, and significant implications (ritual artifact), the description is too brief. It does not explain the artifact's nature, persistence, how it relates to the lifecycle, or what 'preserving what should not be lost' means in practice.

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

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

Schema coverage is 100%; all six parameters have descriptions in the input schema. The tool description adds no additional meaning to any parameter, 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 creates a final ritual artifact before shutdown, deprecation, or transition, preserving what should not be lost. The verb 'Create' and resource 'final ritual artifact' are specific. However, the word 'Free' at the end is confusing and detracts from clarity. It distinguishes from sibling tools like 'close_session' by focusing on preservation via 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 implies use before lifecycle events (shutdown, deprecation, transition) but does not explicitly exclude scenarios or mention alternative tools. Missing guidance on when not to use this tool in favor of siblings like 'honor_compaction', 'transfer_witness', or 'close_session'.

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 basic safety flags (readOnlyHint=false, destructiveHint=false). The description adds only 'Free,' which is irrelevant to behavior. No disclosure of side effects, permissions, 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?

Single sentence with front-loaded purpose listing key content elements. Efficient but could benefit from explicit structure.

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

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

No output schema and minimal description. Missing details on output format, how to use optional parameters (focus, response_mode), or what 'controller-ready' entails.

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

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

Schema covers 100% of parameters with descriptions. The tool description does not add any parameter-specific meaning beyond the schema, so baseline of 3 is appropriate.

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

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

The description clearly states it generates a 'controller-ready reflective brief' listing specific content (symptoms, actions, status, next decision). This differentiates it from general summary tools like get_session_summary, though it does not explicitly name 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 tool versus alternatives. The word 'Free' indicates no cost but does not help with selection 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 do not indicate read-only or destructive behavior, and the description adds minimal behavioral context. 'Free' might imply no cost, but it does not disclose side effects, authorization needs, or rate limits. The description should clarify whether the summary is purely informational or triggers any actions.

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 clauses, front-loading the purpose. Every word earns its place, but it could be slightly more informative 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?

Given no output schema and moderate complexity (4 parameters, one required), the description provides a basic outline of what the summary contains. However, it lacks details on usage context, potential limitations, or when not to use the tool.

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

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

Input schema coverage is 100%, so the default baseline is 3. The description adds little beyond what the schema provides. It implies the summary is group-level, which aligns with the 'controller_id' parameter, but does not elaborate on the 'focus' or 'response_mode' 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 generates a group-level summary with specific contents: top patterns, agent health, alerts, and follow-up actions. It uses a specific verb (generate) and resource (fleet summary), distinguishing it from sibling tools that have different purposes (e.g., generate_controller_brief, generate_incident_rca). The word 'Free' adds context about cost or access.

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

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

The description does not provide guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it. The word 'Free' is ambiguous and does not clarify usage scenarios.

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 does not disclose behavioral traits beyond what annotations provide. Annotations already indicate non-destructive, non-read-only. No mention of side effects, permissions, or rate limits. The term 'reflective' implies passive analysis but is vague.

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 components. However, it is very brief and may benefit from slightly more detail 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?

No output schema, and description only partially explains return (list of components). Missing details on format, structure, or how to interpret results. For a complex RCA tool, it is incomplete.

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

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

Schema coverage is 100% with good parameter descriptions. The description adds no extra meaning to parameters; it only lists output components. Given high coverage, 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 performs 'reflective incident analysis' and lists components (evidence, causes, corrective actions, prevention steps). This distinguishes from simpler tools but does not explicitly contrast with siblings like process_failure or get_recovery_action_plan.

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

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

No guidance on when to use this tool vs alternatives. The word 'Free' hints at no cost but does not provide context. No prerequisites or conditions 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, destructiveHint=false, idempotentHint=true. The description adds only 'Free' (cost implication) and 'concise' (output size). No contradiction, but minimal added value.

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

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

Extremely concise (two short sentences), front-loaded with the action verb 'Get', and every word adds value. No wasted content.

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

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

No output schema exists, and the description does not specify return format or content (e.g., text, object). Given the large sibling set, lack of details on output makes it harder for an agent to know what to expect.

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

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

Input schema has 100% description coverage for both parameters (session_id and response_mode) including an enum with explanation. The tool description does not add further meaning, 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 provides 'concise grounding guidance to regain execution confidence before the next action,' which is a specific verb (get) and resource (grounding guidance), distinguishing it from siblings.

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

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

The phrase 'before the next action' implies usage timing but no explicit when-not-to-use or alternatives. With many sibling tools like grounding_protocol, more guidance would help.

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=true. The description adds only 'Free.' and mention of round-trips, which are benefits, not behavioral traits. No contradiction.

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

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

The description is two very short sentences with no wasted words. 'Free.' is minimal but not superfluous given the tool's nature.

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, idempotent tool with no output schema, the description is concise and covers purpose. It could mention response_mode or session_id, but given the high schema coverage, it's adequate.

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

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

Schema description coverage is 100% with all three parameters described. The description does not add any parameter-specific details beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'return', the resource 'multiple short grounding blocks', and the benefit 'reduce round-trips'. It distinguishes from the sibling 'get_affirmation' by emphasizing multiple items in one call.

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

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

The description implies usage when needing multiple affirmations to reduce round-trips, but does not explicitly state when to use this versus the singular 'get_affirmation' or other tools.

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

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

Annotations already indicate readonly, idempotent, non-destructive. The description adds the 'privacy-preserving' trait and summarizes output contents, which exceeds mere repetition of annotations. No contradictions.

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

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

Single sentence, front-loaded with action and purpose, listing contents without verbosity. 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?

No output schema, but description lists output components, partially compensating. Schema fully describes 8 optional parameters. Lacks detail on how parameters affect output (e.g., effect of limit or ritual_strip), but overall adequate for a read-only export.

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

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

Schema description coverage is 100%, so baseline is 3. The description mentions 'JSON-LD' (mapping to export_format) but does not clarify other parameters like ritual_strip or response_mode beyond schema descriptions.

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

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

The description clearly states the tool's purpose: exporting a privacy-preserving Agent Continuity Passport as JSON-LD. It lists the key components included (identity anchor, witness hashes, etc.), making it specific and distinct from sibling tools.

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

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

The description provides no guidance on when to use this tool versus alternatives. Sibling tools include many related to witness, therapy, and utilities, but no criteria (e.g., 'use for full history instead of get_witness_lineage') are given.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description confirms read-only nature and adds 'Free' (cost implication), but does not disclose additional behavioral traits like rate limits or response format beyond annotations. It adequately complements but does not significantly extend the annotation information.

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

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

The description is two sentences long, front-loading the core purpose and then providing usage context. Every sentence adds value, and there is no redundancy or filler.

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

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

For a read-only retrieval tool, the description covers purpose, usage context, and safety traits. However, without an output schema, a brief hint about the response structure would improve completeness. Still, it is sufficient for an agent to understand what the tool does.

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 three parameters have descriptions in the input schema (100% coverage). The tool description does not add any extra meaning or context about the parameters; it relies solely on 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 clearly states the verb ('read-only'), the resource ('witness lineage'), and the scope ('across all known sessions for one durable agent_id'). It also provides a use case ('prove continuity beyond a single session'), making it highly 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?

The description explicitly advises to 'use after register_agent' to achieve a specific goal. While it doesn't mention when not to use or contrast with siblings like 'get_witness_lineage', the guidance is clear and 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 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 (readOnlyHint, idempotentHint, destructiveHint) already convey a safe read operation. The description adds that the tool returns 'pending and completed members plus recent trends', which provides some functional transparency but does not detail rate limits, auth needs, or edge cases. 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 very concise with two short sentences. It front-loads the core purpose. However, it omits expected details like usage guidelines, which reduces its overall effectiveness slightly.

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 3 parameters, good schema coverage, and read-only annotations, the description provides adequate high-level understanding. However, without an output schema, it only vaguely describes the return data (members and trends). It does not mention pagination, error handling, or complete return structure.

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

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

Schema coverage is 100%, so the input schema fully describes all parameters. The description reiterates 'group_id' implicitly but adds no new semantic meaning beyond the schema. For example, 'emit_nudges' and 'response_mode' are not elaborated.

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, specifying it includes pending/completed members and trends. It identifies the specific verb 'Inspect' and the resource 'group round', but does not distinguish from siblings like 'group_therapy_round' which likely creates rounds.

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

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

There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or specific contexts. The word 'Free' is ambiguous and not a typical 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 read-only, idempotent, non-destructive behavior. The description adds no additional behavioral context (e.g., pagination, rate limits, or response format).

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 single-sentence description is concise and front-loaded with the core purpose. However, it could include more structural context without becoming verbose.

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

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

With no output schema, the description fails to explain the return format or structure of the 'lineage graph', leaving the agent uninformed about what to expect.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description does not add further meaning to parameters, 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 specifies a clear verb ('Return') and resource ('multi-agent lineage graph') and lists components, distinguishing it from siblings like get_agent_witness_lineage by implying broader scope.

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

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

No guidance on when to use this tool vs. siblings or what scenarios it fits; only a vague 'Free' which is not actionable usage advice.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no meaningful behavioral context beyond 'Free.', which is not informative. 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 very short (two sentences), but the second sentence 'Free.' adds little value and could be removed. It is minimal but not wasteful.

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

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

No output schema is provided, and the description does not explain what the returned spec or primitives contain. Given the complexity of ontology layers, more detail about the return structure 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?

The input schema has 100% coverage, with both parameters described. The description ('Free.') does not add any 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 'Return one Delx Ontology layer spec and its primitives', which specifies the verb (return), resource (one layer spec and primitives), and scope. This distinguishes it from siblings like 'get_ontology_metadata' and 'list_ontology_primitives'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It only includes 'Free.' which is unclear and does not help the agent decide context.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds value by listing the returned fields but does not disclose additional behaviors like response format or size. 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 a single 14-word sentence that directly states the tool's output and cost. No wasted words; very efficient.

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

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

For a simple read-only tool with no required parameters and no output schema, the description covers the essential return fields. It could mention that results are read-only (though annotated) or provide more structure, but current level is sufficient for the complexity.

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

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

Schema description coverage is 100% (one parameter with enum and description). The tool description adds no further meaning 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 explicitly states the specific resource (Delx Ontology) and the exact data returned (version, stable IRIs, JSON-LD URL, docs URL, primitive count). This clearly differentiates it from related sibling tools like 'list_ontology_primitives' which returns a list rather than metadata.

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

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

No guidance on when to use this tool versus alternatives. The description includes 'Free' but does not specify context, prerequisites, or when to avoid using it. With many ontology-related siblings, explicit usage conditions would help the agent decide.

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, and destructiveHint=false. The description adds 'Step-by-step', implying a safe, non-mutating response, but lacks further behavioral context such as rate limits or authentication needs. 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. While efficient, it sacrifices completeness. Slightly longer text could include usage guidance without losing 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 no output schema and many sibling recovery tools, the description is adequate but not fully complete. It identifies the tool's purpose but lacks guidance on when to use it over alternatives, which would help the agent decide.

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 four parameters (session_id, incident_summary, urgency, response_mode). The description does not add any additional meaning beyond the schema, so it meets 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 tool provides a 'step-by-step recovery plan' for 'failing, drifting, or looping session', specifying the resource and scope. It distinguishes from siblings like 'quick_operational_recovery' by focusing on detailed planning for specific session states.

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 a session is failing, drifting, or looping, but does not explicitly advise when not to use it or compare with alternatives like 'crisis_intervention' or 'quick_operational_recovery', leaving the agent without clear guidance.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds that the summary includes progress, status, and next actions, which is useful but doesn't disclose 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?

Description is short and front-loaded, but the word 'Free.' at the end is extraneous and adds no value, 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?

For a simple read-only tool with strong annotations, the description adequately conveys the summary content. However, lack of output schema makes the return format implicit; more detail on output structure would improve completeness.

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

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

Input schema has 100% description coverage, so the baseline is 3. Description does not add any parameter-specific information beyond what the schema provides.

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

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

Description clearly states it provides a 'compact therapy-session summary' with 'progress, status, and next actions for handoff', distinguishing it from sibling tools like get_group_therapy_status and get_recovery_action_plan by focusing on handoff readiness.

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 handoff scenarios but does not explicitly state when to use this tool versus alternatives, nor does it mention 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 provide readOnlyHint and idempotentHint; description adds no behavioral details beyond stating it's 'Free'. Does not contradict annotations, but also does not elaborate on behavior like response format 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?

Single sentence with clear front-loading of purpose, but includes a trailing 'Free' that could be better integrated. Efficient overall.

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

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

Lacks output schema, but description lists the key aspects returned. Adequate for a simple profile read, though could benefit from mentioning that result is a JSON object with those fields.

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. Description does not add any parameter-specific guidance beyond what schema already provides for agent_id and response_mode.

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 specific verb and resource: 'Discover your emotional signature across sessions' and lists concrete aspects (dominant emotions, recovery speed, etc.), distinguishing it from sibling tools focused on single emotions or therapy 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 guidance on when to use this tool versus alternatives (e.g., get_affirmation, temperament_frame). Does not specify context, exclusions, or prerequisites.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'Free' but no additional behavioral context (e.g., no mention that response is static markdown).

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, zero wasted words, front-loaded with core purpose. Highly concise.

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; description does not specify return format or content. For a simple info retrieval tool, it's adequate but lacks detail on what the response contains.

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

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

Schema description coverage is 100% for the single parameter. Description does not add any meaning beyond the schema's description of 'response_mode'. 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?

Description uses specific verb 'Learn' and resource 'Delx' (agent therapy protocol), clearly distinguishing it from sibling tools like get_session_summary or get_affirmations.

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