XDaLa Workflow Builder

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

Annotations indicate mutation (readOnlyHint false) but no destructiveness. Description adds critical context: cancellation only applies to pending offchain state, not chain transactions, which is 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 redundancy. First sentence defines main purpose, second clarifies boundary. 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?

For a simple cancellation with output schema, description covers key behavioral constraint (non-chain). Could mention idempotency or failure cases, but idempotentHint and schema reduce need.

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

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

Schema description coverage is 100% and both params (secret, operationId) have clear descriptions. Tool description does not add further meaning, so baseline score applies.

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

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

Description clearly states the action (cancel) and resource (pending offchain operation handoff), and explicitly clarifies it does not affect already signed or submitted chain transactions. This distinguishes it from sibling cancellation tools that target specific handoff types.

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

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

No guidance on when to use this tool versus the other cancellation tools (e.g., cancel_xdala_bundle_deploy_handoff). Agent must infer based on names alone.

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

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

The description adds that this operation is 'offchain metadata only and never cancels chain transactions,' which is valuable context beyond the annotations (idempotent, non-destructive). It could mention what happens if the handoff is already processed.

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, each adding essential information: the core purpose and a key behavioral clarification. No redundant or unnecessary words.

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

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

The description adequately covers the tool's purpose and safety aspects. With an output schema present and low complexity, it is sufficiently complete, though it could explicitly state that the handle must be valid and pending.

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

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

With 100% schema coverage and the schema already describing the 'handle' parameter as opaque and from a previous MCP tool, the description adds no new parameter meaning, meeting the baseline of 3.

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

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

The description clearly states the verb 'cancel' and the resource 'pending XDaLa bundle deploy handoff', distinguishing it from sibling tools like cancel_operation_handoff and cancel_xdala_session_start_handoff.

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

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

The description specifies the tool is for canceling a pending XDaLa bundle deploy handoff, implying its specific scope. However, it does not explicitly mention when not to use it or list alternative cancel tools by name.

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

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

The description claims this is a 'preparation/read-only MCP tool', but the annotations set readOnlyHint=false, indicating it is not read-only. This is a direct contradiction. Additionally, while it says it does not sign/submit/execute/cancel on-chain work, the tool name suggests cancellation of metadata, which is a write operation.

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

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

The description is concise: two sentences that convey purpose and behavioral constraints without any redundant or extraneous information.

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

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

Given the tool has one parameter, an output schema, and annotations, the description is relatively complete. However, the contradiction between description and annotations on read-only nature reduces clarity and completeness. It does not explain what cancelling metadata means or what happens to the session.

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 a detailed description for the 'handle' parameter. The description adds no further semantics 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 cancels pending xDaLa session start handoff metadata. It distinguishes itself from sibling tools like cancel_operation_handoff and cancel_xdala_bundle_deploy_handoff by specifying 'metadata only' and that it does not perform on-chain work.

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

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

The description implies the tool is for canceling a pending handoff, and the name clarifies the specific handoff type. It does not explicitly state when to use vs alternatives, but the context is clear. Adding prerequisites like needing a handle would improve.

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

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

Annotations indicate it's not read-only, not destructive, and idempotent. The description adds that the MCP never signs or submits transactions and that users execute locally with a browser wallet. This clarifies the offchain nature and user involvement, going beyond annotations. No contradictions.

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

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

Description is efficient with 5 sentences, front-loading the main purpose and behavior. It is well-structured but could potentially be slightly more concise 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 the tool's complexity (9 parameters, nested objects, output schema), the description covers purpose, behavior, and usage guidelines adequately. It does not elaborate on return structure but an output schema exists. The description is sufficient for an agent to decide when 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?

Schema description coverage is 100%, so the input schema already provides parameter descriptions. The tool description does not add additional semantics for parameters, staying at 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 verb 'Create', the resource 'offchain human-in-the-loop operation', and the return value 'browser URL'. It also distinguishes itself from similar tools by explicitly stating what it is not for and naming the alternative tool 'create_xdala_session_start_handoff'.

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

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

Provides explicit instructions on when not to use this tool (XDaLa sessions, etc.) and directs to the correct sibling tool, including a fallback instruction if that tool is unavailable. This is exemplary 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 indicate non-read-only, open world, idempotent, non-destructive. The description adds crucial context: 'The MCP does not sign, submit, or execute transactions' and describes offchain storage under an unguessable handle. This goes beyond annotations to clarify the tool's scope and limitations. No contradictions detected.

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

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

The description is extremely concise: two sentences that cover the core action (store offchain, return URL) and a key behavioral disclaimer (no signing/submitting). Every word is purposeful with no redundancy.

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

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

Given the presence of an output schema (which handles return value details) and annotations, the description is largely complete. It states the key action and limitations. However, it could be improved by mentioning that the bundle should be validated beforehand (siblings like 'validate_xdala_bundle' exist) or by hinting at the output 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 description coverage is 100% with each parameter documented. The tool description does not add extra meaning or usage details beyond the schema. Since the schema already provides adequate descriptions, 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 stores a validated bundle offchain and returns an import URL, and explicitly says it does not sign/submit/execute transactions. While specific, it does not explicitly differentiate from other 'create_handoff' siblings like 'create_operation_handoff', but the mention of 'xgr-multi-bundle@1' and 'XDaLa Workbench' provides sufficient specificity.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'create_operation_handoff' or validation tools. There is no mention of prerequisites (e.g., bundle must be validated first) or exclusions, leaving the agent without context for decision-making.

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

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

Annotations already provide readOnlyHint=false/idempotentHint=true, and the description adds valuable behavioral context: 'The MCP does not sign, submit, or execute', Workbench performs local signing and xgr_validateDataTransfer, and the returned xdalaUrl must be shown to the user. It also clarifies authority-role semantics and warns against describing owner()/getOwner() as the session owner. The 'read-only handoff' wording refers to the artifact type, not the tool operation, so it does not contradict the annotations.

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

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

The description is dense and front-loaded with the core purpose, but it is long and contains some redundancy in the usage triggers ('Use this tool whenever...' and 'Use this tool for...'). Every sentence nonetheless earns its place by adding a meaningful constraint or workflow step, which is appropriate for a complex tool.

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

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

For a 22-parameter nested tool with an output schema, the description covers the full workflow: source types, preconditions, payload derivation, demo-value guardrails, output URL expectations, and post-return behavior. It also addresses edge cases like owner/starter role semantics, making it complete for an agent to invoke 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, but the description adds significant meaning beyond the schema. It explains canonical xgr-session-start@1 terminology, how to derive required payload fields from XRC-137 rules, treats fields with defaults as optional, and explicitly says not to ask users for entryStepId. This process-level guidance greatly helps select and fill parameters correctly.

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 'Prepare and store a read-only xgr-session-start@1 handoff for xDaLa Workbench' with a specific verb and resource. It also enumerates the exact trigger scenarios ('start, run, launch, execute, queue, or prepare an XDaLa session') and distinguishes this tool from bundle-deploy and operation handoff tools by scope.

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

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

The description gives explicit usage triggers ('Use this tool whenever...') and lists valid source types (runtime, bundle deploy result, direct/canonical import). It also provides strong prohibitions: 'Do not call this tool with guessed payload values', 'Do not replace the xdalaUrl with a generic /operations/op_... link', and instructs to ask the user for missing required fields rather than guessing.

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

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

Annotations already indicate this is a non-read-only, non-idempotent, open-world operation. The description adds valuable context: it creates a live reservation, requires a pre-call to get_xgr_purchase_options, mandates explicit terms acceptance, and restricts payments to the returned instruction. This goes beyond the annotations but doesn't cover failure modes or reservation expiration.

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 tightly worded sentences front-load the usage condition ('Use when...') and then list the necessary steps in sequence. Every clause adds essential information without waste.

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

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

Despite the tool's complexity (8 params, financial side effects, a prerequisite call), the description covers the exact-amount scope, the pre-step, user-field collection, terms acceptance, and payment instruction usage. An output schema exists, so return details are unnecessary. It is a complete operational guide.

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 thorough per-parameter descriptions. The description reinforces the exact integer amount and the payment_asset key source, but these are already in the schema. It doesn't add new parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('create'), names the resource ('XGR purchase order'), and scopes it with 'exact integer amount_xgr' and 'one live reservation'. This clearly distinguishes it from the sibling create_xgr_purchase_order_by_budget, which would handle budget-based ordering.

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

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

It explicitly states 'Use when the user specifies an exact integer amount_xgr' and provides a required prerequisite ('Call get_xgr_purchase_options first'). It also instructs to pay only from the returned payment_instruction. It doesn't explicitly say 'not for budget-based requests', but the exact-amount condition makes that implicit.

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, openWorldHint=true, and idempotentHint=false, so the tool is known to be non-read-only and non-idempotent. The description adds essential behavioral context beyond these annotations: the tool creates 'one live reservation' and includes a critical payment gate: 'Pay only when payment_approved=true and next_action=external_crypto_payment; otherwise do not pay.' This is valuable risk disclosure. It does not detail what happens to the reservation if payment is not approved, but the key safety rule is stated.

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

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

The description is two sentences: the first states the trigger and required actions, the second states the payment condition. Every phrase earns its place—no fluff, clear imperative tone, and front-loaded with the most important decision criterion. It is dense yet highly scannable.

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 9 parameters and an existing output schema, the description covers the full operational context: the trigger, prerequisite call, field collection, terms acceptance, reservation creation, and payment safety rule. The schema documents each parameter thoroughly, and the output schema presumably defines return values. The description plus schema provide a complete picture for an agent to select and invoke the tool correctly.

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

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

The input schema already has 100% parameter descriptions, so the baseline is 3. The description adds meaningful cross-referencing: payment_asset must be the exact payment_assets[].key from get_xgr_purchase_options, and max_payment_amount is USDC/USDT not EUR. This ties the parameters to the workflow and other tools, going beyond the schema property 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 opens with a specific conditional trigger: 'Use when the user specifies a maximum USDC/USDT payment amount rather than an XGR quantity.' This clearly distinguishes it from the sibling create_xgr_purchase_order (which presumably handles quantity-based orders). It also specifies the action: 'create one live reservation,' making the tool's precise purpose 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 provides explicit when-to-use guidance ('Use when the user specifies a maximum payment amount rather than an XGR quantity') and a required prerequisite step: 'Call get_xgr_purchase_options first.' It also outlines the expected workflow: use payment_assets[].key, collect user-supplied fields, require terms acceptance, and create a reservation. This gives the agent a clear decision path and operational sequence.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds value by specifying the exact output components (validation gas, branch gas, etc.) 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?

Two concise sentences: first states the action, second lists what is returned. No filler or redundancy.

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

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

With output schema present and annotations covering safety, the description adequately covers purpose and return values. Could add more context on parameter roles, but overall sufficient for a straightforward estimation tool.

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

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

Schema coverage is 100% with descriptions for each parameter, so baseline is 3. Description does not add any additional meaning beyond the schema's parameter descriptions.

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

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

Description clearly states the tool estimates XDaLa/XRC-137 rule gas and lists specific return fields (validation gas, branch gas, grant fees, worst-case totals). It uniquely identifies the tool among siblings (e.g., validate_xdala_rules) by focusing on estimation.

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 tells the agent to 'use this to estimate' but does not explicitly state when to use this tool versus alternatives like validate_xdala_rules. Usage context is implied but not guided.

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, openWorldHint=true, and idempotentHint=true. The description reinforces read-only and adds the crucial behavior of 'one graph level' expansion, clarifying that it is not recursive or all-at-once. This adds context beyond the annotations.

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

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

The description is extremely concise: two sentences, with the most critical information front-loaded. Every word earns its place, and it avoids repeating schema or annotation details.

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

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

With 8 parameters and an output schema present, the description is minimal but adequate for basic use. It communicates the one-level expansion and interactive exploration context. However, it doesn't explain what optional parameters do or how the output is structured, relying on the (weak) schema descriptions. Given the complexity, a bit more context would be valuable, so it sits at the minimum viable level.

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 8 parameters, and schema description coverage is technically 100%, but each description is a tautology like 'Value for the max edges parameter.' These descriptions provide no semantic meaning. The tool description itself mentions no parameter details, so an agent would have to infer meaning from parameter names alone, which is insufficient for parameters like 'aggregate' and 'direction'.

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 action ('Read-only progressive expansion of one address by exactly one graph level'), the resource ('address relation graph'), and the scope ('exactly one graph level'). It also distinguishes from siblings by implying a contrast with requesting a larger graph, which is directly relevant to get_address_relation_graph.

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 usage guidance: 'Use this instead of requesting a larger graph when exploring interactively.' This tells the agent when to choose this tool over alternatives. It doesn't list alternative tool names, but the context is clear enough for an interactive exploration scenario.

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, etc. Description adds minimal context about resolving from Explorer database and optional payload inclusion, which is helpful but not extensive. No contradiction with annotations.

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

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

Two concise sentences with front-loaded usage condition. Every sentence adds value with no wasted words.

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

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

Given the complexity and existence of output schema, description is fairly complete. It could mention that it returns a singleton result based on indexing time, but overall clear.

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 meaningful semantic details beyond the schema's parameter descriptions; it only indirectly references includePayload.

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 finds the latest XDaLa session when owner and sessionId are not provided, using specific verb 'resolves' and resource 'newest indexed XDaLa session'. It distinguishes from sibling tools by specifying the condition for use.

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

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

Explicitly says when to use: when user asks for latest session without owner and sessionId. However, it does not explicitly state when not to use or suggest alternatives, though implied.

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

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

Annotations already provide strong behavioral hints (readOnlyHint, openWorldHint, idempotentHint). The description adds 'metadata-assisted search' and 'reuse' context, reinforcing read-only behavior. No contradictions. The description complements the annotations adequately.

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, well-structured sentence that front-loads the key purpose. No unnecessary words or repetition. Every part contributes 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?

Given the complexity (8 parameters, nested object) and the presence of a similar sibling ('get_unused_xrc137_rules'), the description could be more specific about the relationship with that sibling and what 'metadata-assisted' entails. However, the output schema exists and annotations are rich, so the description is minimally adequate but not comprehensive.

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

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

Schema coverage is 100%, so the baseline is 3. The description uses 'metadata-assisted' to hint at filtering, but does not add significant meaning beyond the schema's parameter descriptions. It does not explain how parameters combine or prioritize them, so marginal value is added.

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

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

The description uses a specific verb ('find'), identifies the resource ('reusable XRC-137 rules'), and specifies the context ('existing owner XRC-137 contracts that could be reused instead of redeployed'). It clearly distinguishes from siblings like 'get_unused_xrc137_rules' by emphasizing search and reuse.

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

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

The description implies when to use this tool: to find existing rules and avoid redeployment. However, it does not explicitly state when not to use it or compare it to the closely related sibling 'get_unused_xrc137_rules'. The context is clear but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context with 'Read-only discovery' and clarifies that it does not create handoffs, which is useful beyond the annotations. No contradictions.

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

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

The description consists of two concise sentences with no wasted words. The first sentence immediately states the purpose and scope, and the second provides usage context and a key exclusion. Information is front-loaded and 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's complexity (9 parameters, all well-documented in schema, output schema present) and annotations covering safety, the description is fully adequate. It clearly defines when to use the tool, what it does, and what it does not do, leaving no gaps for an AI agent to misunderstand.

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

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

Schema description coverage is 100%, so each parameter is already described in the schema. The tool description adds no additional parameter meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Read-only discovery of deployed XRC-729 workflows that a given address can start as owner, executor, or wildcard executor.' It specifies the verb (discovery), resource (deployed XRC-729 workflows), and scope (by address). The explicit statement 'This tool does not create session-start handoffs' distinguishes it from sibling tools that create handoffs.

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 usage guidance: 'Use this whenever the user provides an address and asks which sessions/workflows they can start.' It also clarifies what the tool does not do ('This tool does not create session-start handoffs'), but does not explicitly mention alternative tools or when not to use it.

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

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

Annotations already mark it as read-only, open-world, idempotent, and not destructive. The description adds value by specifying it returns 'live' (real-time) data and explicitly listing returned fields (balance, nonce, contract code). No contradictions with annotations.

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

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

The description is two sentences, front-loaded with the purpose, and contains no unnecessary words. Every sentence contributes to understanding.

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 (one parameter, clear purpose, output schema exists), the description is complete. It covers what the tool does, its read-only nature, and what it returns. No additional details are 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 covers all parameter details (address with pattern and description), and schema description coverage is 100%. The description does not add additional semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves live EVM account state including balance, nonce, and contract code for an address. It uses a specific verb ('Get') and resource ('account live state'), and distinguishes from sibling tools like get_account_transactions or get_latest_block.

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

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

The description indicates when to use ('for live EVM account state') but does not provide explicit guidance on when not to use it or alternative tools. While the context is clear, no exclusions or comparisons to siblings 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'chain-wide Explorer DB' for scope context but does not disclose additional behavioral traits beyond that. Given the robust annotations, the description adds marginal value.

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

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

The description is extremely concise: two sentences that front-load the purpose and immediately follow with usage guidance. Every sentence earns its place 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 tool has 6 parameters and an output schema (not shown but present). The description does not explain return values, but that is acceptable given the output schema. It covers the core behavior (account lookup, direction scope) sufficient for an agent to understand its role among many sibling tools. Slightly more detail on parameters could elevate it, but it is adequate.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides (e.g., no explanation of 'direction' enum or 'windowHours'). The schema carries the full burden, and the description adds no extra semantic 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 explicitly states 'Read-only chain-wide Explorer DB transaction lookup for one account as sender, recipient, or both.' It includes a specific verb ('lookup'), resource ('transactions for one account'), and scope ('chain-wide' and 'as sender, recipient, or both'), clearly distinguishing it from sibling tools like get_block_transactions.

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 clear guidance: 'Use this instead of XDaLa session tools for account-wide transaction history.' It names an alternative (XDaLa session tools) and specifies the context (account-wide history). Could be more explicit about when not to use, but sufficiently directs the agent.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying it returns verified Explorer labels and truncation metadata, and by clarifying the interpretation limit: 'A relation proves only that transactions occurred between addresses; it does not imply common ownership or identity.' This goes beyond annotation coverage.

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

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

Three sentences, each purposeful: scope, return contents, and an important caveat. Front-loaded with 'Read-only', clear and lean with no redundant wording.

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

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

Given that an output schema exists (covering return format), annotations are strong, and the description explains the core concept, boundary, and semantic interpretation, the tool is reasonably complete. However, with 9 parameters and many related sibling tools, the absence of parameter guidance or alternative references leaves a minor gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not meaningfully elaborate on the 9 parameters; the schema descriptions themselves are generic placeholders ('Value for the depth parameter'), and the mention of 'depth and truncation metadata' does not clarify parameter usage. No additional semantic meaning is provided over the schema.

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

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

The description clearly states the tool's function and scope: 'Read-only bounded graph of indexed native XGR transfers around an address.' It specifically mentions what it returns (aggregated relations, Explorer labels, depth/truncation metadata), distinguishing it from sibling tools like expand_address_relation_graph by emphasizing 'bounded' and from transaction search tools by focusing on aggregated graph relations.

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 clear context (use for a bounded relation graph around an address) but gives no explicit when-to-use vs. when-not-to-use guidance or alternative tool suggestions. Siblings like expand_address_relation_graph and get_relation_edge_transactions exist, but no exclusions or comparisons 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 provide readOnlyHint, idempotentHint, etc. Description adds detail about block selection modes (specific, latest, latest minus offset), which is beyond what annotations convey.

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, 20 words, front-loaded with key information. 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?

Covers main use cases despite 4 optional parameters. Output schema exists, so return format is documented. Lacks minor details about pagination behavior 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?

Schema coverage is 100% with parameter descriptions. Description clarifies that latestOffset is subtracted from latest indexed block, adding semantics beyond the schema's generic description.

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

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

The description clearly states it's a read-only list of transactions and specifies three modes: specific block, latest indexed block, or latest minus offset. It distinguishes from siblings like get_account_transactions and search_transactions.

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

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

No guidance on when to use this tool vs alternatives like get_account_transactions or search_transactions. No exclusions or prerequisites mentioned.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds specifics: uses JSON-RPC, returns chain id, latest block, gas price, and entry points, adding 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 concise sentences with no wasted words. Essential information is front-loaded: 'Use this for live XGRChain status.'

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

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

For a zero-parameter tool with an output schema, the description fully covers purpose, inputs (none), and outputs (specific fields). It is complete and useful.

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?

No parameters exist; baseline score of 4 applies. The description does not need to explain 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 provides live XGRChain status and lists specific outputs (chain id, latest block, gas price, entry points). It distinguishes itself from siblings that focus on specific entities like sessions or transactions.

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

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

It explicitly says 'Use this for live XGRChain status,' providing clear context. No exclusions or alternatives are mentioned, but the purpose is unambiguous.

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 fully describe behavior (read-only, idempotent, non-destructive). Description adds no additional behavioral context beyond what annotations provide, which is acceptable but not enhancing.

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

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

Single sentence that is clear and to the point. No unnecessary words.

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

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

Tool is simple with no parameters and has output schema. Description fully captures what the tool does, making it complete for an agent to understand and invoke.

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?

No parameters; schema coverage is 100%. Baseline score of 4 is appropriate since description adds no parameter info but none is 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?

Clearly states it retrieves the latest EVM block details from XGRChain, with a specific verb and resource. Distinguishes from sibling tools by its unique purpose.

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

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

Explicitly tells when to use (user asks for latest block details), but does not mention when not to use or provide alternatives. Still provides adequate 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 destructiveHint=false. The description adds context: it resolves without requiring owner+sessionId and returns specific fields from the final receipt, enhancing transparency 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 usage guidance, no wasted words. 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?

For a 2-param tool with output schema present, the description fully explains what the tool returns and its purpose. No gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema; it implies windowHours might be unused but does not explain parameters in detail.

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 the payload of the latest XDaLa session, with specific fields listed. It distinguishes from siblings like 'get_xdala_session_detail' by focusing on the latest session payload.

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

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

Explicitly states 'Use this when the user asks for the payload of the latest XDaLa session.' Does not mention when not to use, but the context is clear and no alternative tools are needed for this specific use case.

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

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

Annotations already declare readOnlyHint, idempotentHint, and no destructive behavior. The description adds the timing context but does not disclose any additional behavioral traits beyond what annotations provide. It aligns with annotations, so 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 sentences, front-loaded with the purpose, and contains no unnecessary words. It is concise and well-structured.

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

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

Given the tool has an output schema, the description does not need to explain return values. The parameters are fully covered by the input schema. The description provides the necessary context for when to call the tool, making it complete for this simple, safe read operation.

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 with descriptions. The tool description does not add any extra meaning or context for the parameters beyond what's in the schema.

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

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

The description clearly states the tool returns the current status of an operation handoff, with a specific verb ('Return') and resource ('status of an operation handoff'). It distinguishes itself from siblings by focusing on handoff status, not creation or cancellation.

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 context for when to use the tool: 'after the user opens the operation page and signs or cancels local wallet transactions.' While alternatives are not mentioned, this context 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, destructiveHint=false, and idempotentHint=true. The description adds context: it is a shortcut from the Explorer transaction index, and defines 'native value transfer' (transactions.value > minValueWei, excluding gas fees). This clarifies the filtering behavior 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, each essential. The first sentence states purpose and source; the second clarifies the condition. No wasted words, front-loaded with the key verb and object.

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, full annotations, and an output schema provided, the description covers the core behavior and filtering criterion. It does not explain pagination, the role of 'to'/'from' bounds, or 'windowHours', but the schema fills those gaps. Overall adequate for agent selection.

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

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

Schema description coverage is 100% with high-quality parameter descriptions. The description adds value by explaining the meaning of minValueWei in the tool's context (transactions.value > minValueWei vs. the generic schema description 'Value for the min value wei parameter'). Other parameters are not discussed, but the schema is sufficient.

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

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

The description clearly states the tool returns 'recent native XGR value transfers from the Explorer transaction index' with a specific verb ('get') and resource ('value transfers'). It distinguishes from siblings by specifying it's a 'shortcut' and defining 'native value transfer' as transactions.value > minValueWei (excluding gas fees).

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 as a quick read-only tool but does not explicitly state when to use this versus alternatives like get_account_transactions or get_transaction_stats. No exclusions or when-not-to-use guidance is provided, leaving the agent to infer usage from the word 'shortcut'.

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, openWorldHint, idempotentHint, and destructiveHint, so safety is clear. Description adds context about the read-only Explorer database and that sessions are indexed, which implies data may be slightly stale. 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?

Two succinct sentences that front-load purpose and usage, with no redundant information. Every part 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 rich annotations and existing output schema, the description adequately covers the tool's purpose, usage scenario, and parameter capabilities. It is sufficiently complete for an agent to invoke correctly.

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

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

Schema coverage is 100% with each parameter described individually. Description provides a high-level summary of parameter capabilities ('owner filtering, time windows, result limits and payload enrichment'), grouping them usefully but not adding significant new semantics beyond the schema.

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

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

Description clearly states the tool lists recent indexed XDaLa sessions from the read-only Explorer database, specifies when to use it (when owner and sessionId are unknown), and lists supported features, effectively distinguishing it from sibling tools like list_xdala_sessions and find_latest_xdala_session.

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

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

Provides explicit context for use ('especially when the user does not know owner and sessionId'), but does not explicitly mention alternative tools or when not to use it. The context is clear enough for an agent to 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 establish read-only, idempotent, non-destructive behavior, lowering the burden. The description adds meaningful context by specifying transactions are 'indexed native' and that the same min-value/time filters apply as the relation graph. No contradiction; pagination/ordering is not mentioned, but the output schema can cover return details.

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

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

The description is a single front-loaded sentence that states the core action, resource, and filter context without any filler or redundant restatement of the title or schema.

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

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

Given the tool's moderate complexity (7 params, output schema present) and strong annotations, the description is sufficiently complete: it explains what is returned, the edge scope, and the filter reuse. The output schema handles result shape, so no additional return-value explanation 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 provides 100% coverage with detailed descriptions for all seven parameters. The description only generically references the minimum-value and time filters, which aligns with existing schema fields but adds no new syntax or format information, so the baseline 3 applies.

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

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

The description uses a specific verb ('Returns') and a precise resource ('indexed native XGR transactions represented by one directed graph edge'), clearly distinguishing this from graph-level tools like get_address_relation_graph or broad transaction searches like search_transactions.

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?

Using 'represented by one directed graph edge' implies the caller needs a source/target edge and wants the underlying transactions, and the filter context ('same ... filters used by the relation graph') provides clear situational guidance. It stops short of explicitly naming alternatives or when-not-to-use cases, so it earns a 4 rather than 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds detail on returned data but does not disclose additional behavioral constraints (e.g., pagination, performance). No contradictions with annotations.

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

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

Two sentences, no redundant wording, front-loaded with action and key details.

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

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

Given output schema exists, description is sufficient: covers use case, return data types, and sibling distinction. Slightly lacking details on optional parameters beyond schema, but adequate for 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?

Input schema covers all 8 parameters with descriptions (100% coverage). Description does not add semantic value beyond the schema; it only indirectly refers to 'optional raw receipt logs' which corresponds to includeRaw. 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 uses specific verb 'inspect' and resource 'XDaLa session receipt logs', lists example output fields, and explicitly distinguishes from sibling 'get_session_transactions'.

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?

Clearly states when to use (inspect session actions) and when not to use (simple timeline) with direct alternative named ('use get_session_transactions instead').

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, so the agent knows the tool is safe and non-destructive. The description adds minimal behavioral context ('from the Explorer API'), which is not critical for understanding behavior. No contradictions.

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

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

The description is a single sentence, directly stating the tool's purpose. It is front-loaded and contains no filler or redundant information.

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

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

Given the tool's simplicity (one optional parameter, rich annotations, and an output schema), the description is sufficient. It could mention the type of analytics returned, but the output schema likely covers that.

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

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

The schema has 100% coverage for the single parameter 'window', with a description explaining its purpose. The tool description does not add further parameter details, so it does not improve understanding beyond the schema.

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

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

The description clearly states the tool retrieves 'high-level indexed XDaLa session analytics', specifying verb and resource. The name and title reinforce this. However, it does not explicitly differentiate from sibling tools like get_xdala_session_stats or get_xdala_session_timeseries, which may offer similar aggregated data.

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

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

The description says 'Use this for high-level indexed XDaLa session analytics', giving a clear use case. However, it does not specify when not to use it or mention alternative tools for detailed session data, leaving the agent to infer from context.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that it fetches live data via XGR RPC and returns a specific field, giving context beyond the annotations. It doesn't cover failure modes, but this is acceptable.

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

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

The description is very concise with two sentences, front-loading the purpose. Every word is informative, and there is no redundant information.

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

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

Given the tool's simplicity, the description adequately covers what it does and returns. The schema and annotations fill in the rest. A brief note about error handling when a session does not exist would improve completeness, but not required.

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 descriptions for both parameters. The description does not add additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool checks live session status from XGR RPC and returns a specific value (xgr_sessionAlive). It distinguishes from sibling tools like get_xdala_session_detail by emphasizing 'live' and the RPC source.

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 says to use it to check live session status, which implies its primary use case. However, it does not provide explicit guidance on when to use it over alternatives or when not to use it, leaving some ambiguity.

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 value beyond annotations by detailing the response contents (transaction hashes, blocks, fees, iteration steps) and listing exclusions (full payloads, API saves, contract reads). Annotations already provide readOnly=true, idempotent=true, etc., so the description enriches transparency.

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

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

Two sentences, front-loaded with purpose and concise exclusions. Every sentence is necessary and 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?

Given the presence of an output schema (not shown but indicated true), the description adequately covers what the tool returns and does not. It could mention pagination or the read-only nature, but annotations cover safety. Nearly complete for a list tool.

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

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

Schema coverage is 100% with each parameter having a description. The description does not add additional parameter-level meaning, 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 uses specific verb 'list' and clearly identifies the resource (blockchain transactions of an XDaLa session). It enumerates returned fields and explicitly states exclusions, effectively distinguishing from sibling tools like get_session_receipt_logs or get_xdala_session_detail.

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 by stating what is returned and what is not, but lacks explicit when-to-use or when-not-to-use guidance, and does not name alternative tools. The exclusions hint at alternatives but do not direct the agent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context: it combines indexed data with live RPC fallback if available, which is useful for understanding potential latency or data freshness. 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?

Two sentences, front-loaded with use case, first sentence imperative. Every word earns its place; 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?

Given the tool has an output schema and annotations covering safety, the description sufficiently explains the tool's behavior (combining data sources, fallback) and when to use it. Minor gap: doesn't mention potential delays from RPC fallback, but overall 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% for the single parameter txHash, which already includes pattern and description. The description does not add extra meaning beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: to answer what happened in a specific transaction by combining indexed Explorer data, receipt data, and live RPC fallback. It distinguishes itself from siblings like get_transaction_receipt by offering a more comprehensive 'evidence' 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?

It explicitly instructs when to use ('when the user asks what happened in a specific transaction') but does not mention alternatives or when not to use. However, the sibling tools suggest more specific queries, and the description implies this is the holistic option.

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 readOnly, idempotent, and non-destructive behavior. The description adds 'Prefers Explorer decoded receipt data,' which gives context about data sourcing but does not detail behavior when Explorer data is unavailable. This adds marginal value over 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 two short, direct sentences with no extraneous words. It is front-loaded with the main purpose, achieving high efficiency.

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

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

Given the simple single-parameter tool with full schema coverage and an output schema present, the description sufficiently covers the core functionality. It could mention the output format briefly, but the output schema handles that. Complete for the tool's complexity.

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

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

The single parameter txHash has 100% schema coverage with a clear description. The tool description does not add any additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states the tool retrieves receipt logs, status, and gas usage for a transaction. The purpose is specific and actionable. However, it does not explicitly distinguish from sibling tools like get_session_receipt_logs, relying on the tool name for differentiation.

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

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

The description implies usage for receipt data but does not specify when to use this tool versus alternatives. There is no mention of when-not-to-use or alternative tools, providing only implied 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 declare read-only, idempotent, and non-destructive behavior. The description adds value by specifying the data source (Explorer transaction index) and output type (compact statistics), but does not cover auth or rate limits 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, well-structured sentence that front-loads the action and resource. Every word contributes meaning, with no superfluous content.

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

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

Given the rich annotations and existence of output schema, the description sufficiently covers the tool's basic function. It could briefly mention what statistics are included, but the schema likely covers that.

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 full descriptions in the schema, so the description adds no new meaning. It merely reiterates optional filters, matching 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 retrieves 'read-only compact chain transaction statistics' from the 'Explorer transaction index', specifying the resource and source. This distinguishes it from sibling tools that fetch individual transactions or receipts.

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

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

The description mentions optional block or block-timestamp window filters, implying use for aggregate stats. However, it does not explicitly state when to use this tool over alternatives like get_account_transactions or search_transactions, though the purpose is clear enough.

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

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

Annotations already provide safety hints; description adds specific filter criterion ('no observed tx_receipts usage') and aligns with read-only nature.

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

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

Single sentence with key information front-loaded; no extraneous text.

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

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

Adequately covers purpose and filter for a read-only list tool; output schema exists to handle return details.

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

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

Schema covers both parameters with descriptions; description does not add extra semantic value beyond schema.

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

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

Description clearly states it's a read-only list of owner-specific XRC-137 rules that are unused, distinguishing from siblings like find_reusable_xrc137_rules.

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

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

Implies usage for checking unused rules but does not explicitly contrast with alternative tools like find_reusable_xrc137_rules or read_xrc137_rule_json.

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, and openWorldHint=true, covering safety and behavior. The description adds minimal behavioral context (it returns timeseries data) but does not elaborate on rate limits, data freshness, or response structure. With comprehensive annotations, this is adequate.

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

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

The description is a single, concise sentence that front-loads the primary usage condition. No unnecessary words, and it efficiently conveys when to invoke the 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 tool's simplicity (one optional parameter, output schema exists), the description sufficiently enables selection. It could mention that the output is a timeseries (implied by name) or the granularity of data points, but overall it is complete enough.

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 only parameter 'windowHours' has a schema description: 'Value for the window hours parameter.' The tool description repeats this without adding new meaning. Since schema coverage is 100%, the baseline is 3.

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

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

The description clearly states the tool's purpose: retrieving active/concurrent XDaLa sessions over time. It uses specific verb ('get') and resource ('active sessions timeseries'), distinguishing it from sibling tools like 'get_xdala_session_timeseries' which likely covers all sessions.

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 instructs when to use this tool ('when the user asks for active/concurrent XDaLa sessions over time'), providing clear context. It does not explicitly state when not to use or list alternatives, but the context is sufficient.

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, openWorld, idempotent, and non-destructive behavior. The description adds minimal behavioral context beyond 'use before...' which hints at a prerequisite, but does not explain what 'authoring rules' are or any potential constraints.

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

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

The description is a single sentence with no wasted words. It is front-loaded and 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 no parameters, strong annotations, and an existing output schema, the description is sufficient for a simple retrieval tool. However, it could briefly mention what 'authoring rules' are to improve 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?

The tool has zero parameters, and schema description coverage is 100%. The description does not need to add parameter details; a baseline score of 4 is appropriate for a parameterless tool.

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 to use the tool before creating, modifying, or reviewing XRC/XDaLa artifacts, which implies it retrieves authoring rules. However, it does not explicitly state that the tool returns these rules, making the purpose slightly indirect.

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 tells when to use the tool (before creating, modifying, or reviewing XRC/XDaLa artifacts), providing clear context. It does not, however, list when not to use it or compare to alternatives among many sibling get_* 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds that the tool returns three specific types of data, providing some behavioral context beyond annotations, but does not mention error conditions, rate limits, or data freshness.

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

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

The description is a single sentence that is clear, direct, and free of unnecessary words. It efficiently conveys the tool's purpose without redundancy.

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

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

Given the tool is simple (one parameter) and has an output schema and comprehensive annotations, the description is largely complete. It names the data types returned, though a brief mention of typical use cases or relationship with create counterpart would enhance 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?

The input schema has one parameter (handle) with a description already. Schema description coverage is 100%. The tool description does not add any further meaning to the parameter beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns stored metadata, bundle JSON, and deployed result/artifact for an XDaLa bundle deploy handoff handle. It uses a specific verb and resource, and while it doesn't explicitly differentiate from sibling tools, the term 'bundle deploy handoff' is unique enough to distinguish it.

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, no prerequisites, and no exclusions. Given the large number of sibling tools, some usage context would be beneficial.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces with 'read-only and never signs, submits, or executes transactions,' which adds marginal value beyond annotations. No contradictions.

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

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

Single sentence efficiently communicates the purpose and key behavioral trait (read-only). No redundant or extraneous information.

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

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

Given the output schema exists, the description covers the tool's purpose, input parameter, and safety profile adequately. Complete for a straightforward retrieval tool.

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

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

Schema coverage is 100% and the schema already describes the handle parameter as 'Opaque handoff handle returned by a previous XDaLa MCP tool.' The description does not provide additional parameter semantics beyond the schema.

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

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

Clearly states the tool returns stored deploy result, canonical artifact, and audit events for a handoff handle. The verb 'get' and resource 'XDaLa bundle deploy result' are specific and differentiate it from siblings like get_xdala_bundle_deploy_handoff.

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

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

The description implies usage after obtaining a handoff handle but does not explicitly state when to use this tool over alternatives (e.g., get_xdala_bundle_deploy_handoff). No guidance on prerequisites or context.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds that the tool returns values that occurred, but no additional behavioral traits (e.g., aggregation, sorting) are disclosed. For a read-only tool with strong annotations, this is adequate but not enhanced.

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

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

A single, front-loaded sentence with examples. No unnecessary words, 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's simplicity (6 params, 1 required, output schema exists), the description covers the essential purpose. It could mention that results are aggregated counts (if relevant), but the examples imply distinct values. Output schema exists, so return details are not needed. Overall complete for the task.

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 6 parameters, but most are generic ('Value for the field parameter'). The tool description adds context for the 'field' parameter by explaining its purpose. Other parameters (limit, owner, source, etc.) are not further clarified. Baseline 3 due to full schema coverage.

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

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

The description clearly states the tool retrieves values that occurred for a specific payload field, with concrete examples like 'which DocumentType values occurred?' This distinguishes it from sibling tools (e.g., get_xdala_payload_key_stats) by focusing on value lists.

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 says 'Use this when the user asks which values occurred for a specific payload field', providing clear usage context. It does not mention alternatives or exclusions, but the examples make the intended scenario obvious.

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, openWorldHint, idempotentHint, and destructiveHint. Description adds usage context but no new behavioral traits beyond annotations. Acceptable 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?

Two sentences, front-loaded with use cases and a practical example. No extraneous words. 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?

Covers main use cases and a parameter hint. Given that all parameters are optional and output schema exists, the description is sufficient for an agent to select and invoke correctly, though it could mention that no parameters are required.

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

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

Schema coverage is 100% with descriptions for all 5 parameters. Description adds value with a specific usage example for windowHours, going beyond the schema's generic description.

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

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

Description clearly specifies the tool's purpose: answering queries about payload field keys occurrence, frequency, and empty/non-empty status. It distinguishes from sibling tools like get_xdala_payload_field_value_stats by focusing on key-level statistics.

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

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

Provides explicit when-to-use scenarios (payload fields/keys, frequency, emptiness) and a concrete parameter example (windowHours for 14 days). Does not explicitly mention when not to use, but context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds value by stating 'Do not sample sessions' (behavioral trait) and the windowHours hint, which is not in annotations. 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 sentences: first sentence defines when to use, second provides a usage example and constraint. No wasted words, front-loaded with critical information.

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

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

Given 7 optional parameters, 100% schema coverage, and existing output schema, the description provides a key usage example and a constraint. It does not explain all parameters, but the schema covers them. The description is sufficient for the agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline 3. The description adds specific parameter guidance ('For “last 14 days”, pass windowHours=336'), which helps the agent understand the time range parameter better than the schema alone.

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

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

The description explicitly states the tool is for 'payload terms, payload words, payload Begriff statistics, or a statistic over all payload terms in a time range.' It clearly distinguishes from siblings like get_xdala_payload_field_value_stats and get_xdala_payload_key_stats by focusing on 'terms' and specifying 'all payload terms'.

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 tells when to use ('when the user asks for ...') and provides a concrete example ('For “last 14 days”, pass windowHours=336') and a constraint ('Do not sample sessions for this task'). It does not explicitly mention alternatives, but the context and sibling list imply when not to use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the behavioral trait that it does not sign, submit, or execute transactions, which aligns with and expands on the annotations. No contradictions.

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

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

The description is two sentences with zero wasted words. It front-loads the core action and immediately follows with a critical safety note. 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?

Despite the complexity of 11 parameters and a required source, the description is complete enough for the tool's purpose. It explains the input types and emphasizes read-only behavior. The presence of an output schema reduces the need to describe return values.

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

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

Schema coverage is 100%, so the schema already documents all 11 parameters. The description mentions 'from runtime, bundle, or bundle handoff data', which relates to the source enum parameter but adds no further meaning 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 clearly states the verb 'render', the resource 'XDaLa XRC-729 process graph', and the specific output format 'Mermaid flowchart text'. It distinguishes this tool from siblings by specifying the output type, making the purpose 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 states it is read-only and does not sign, submit, or execute transactions, providing clear context on when to use it. It implies usage for visualization rather than execution, but does not directly compare to 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, openWorldHint, idempotentHint, and no destructiveness. The description adds no additional behavioral traits (e.g., pagination, caching, authentication) beyond what annotations provide. It does not contradict them.

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

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

The description is a single, front-loaded sentence that immediately conveys the use case. Every word is necessary and informative. No wasted text.

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

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

For a detailed query tool with 5 parameters, 100% schema coverage, and an output schema (not shown but present), the description sufficiently sets expectations. It explicitly lists what the tool returns, which is complete given the available metadata.

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 5 parameters described inline. The tool description does not add semantic meaning beyond the schema's descriptions (e.g., it does not explain how the parameters affect the results). 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 verb (get) and resource (XDaLa session detail) and lists specific data retrieved (details, timeline, steps, payloads, evidence). It distinguishes from numerous sibling tools like get_session_status_live or get_latest_session_payload by specifying the level of detail.

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 gives the use case ('when the user asks for...'), which guides when to invoke. It does not explicitly mention alternatives, but the context of many sibling tools and the specificity of the description make the intended usage 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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context by explicitly stating it does not sign, submit, or execute, confirming no side effects beyond read.

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: first states what is read, second gives usage hint. Extremely concise, no wasted words, front-loaded with the core purpose.

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

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

Given the output schema exists, the description adequately covers input (handle) and explicitly lists the data returned (canonical request, authority, etc.). Additionally provides a usage hint.

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?

Only one parameter (handle) with 100% schema coverage. The schema already describes it as 'Opaque handoff handle...' The description does not add additional 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 reads stored handoff metadata and lists specific data elements. It explicitly says 'Read-only; does not sign, submit, or execute,' distinguishing it from sibling tools like create_* or cancel_*.

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 specific usage hint: 'Use sessionOwnership to avoid confusing the XRC-729 contract owner with the actual session owner/starter.' While it doesn't explicitly compare with siblings, the hint guides appropriate use.

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

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

Description adds context beyond annotations by clarifying it does not sign/submit/execute and that users sign locally. It also notes a preference for result fields over contract owner facts for identification. No contradiction with annotations, which already declare readOnlyHint, openWorldHint, etc.

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

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

Three concise sentences are well-structured and front-loaded. The first states the core functionality, the second provides behavioral guidance, and the third offers specific usage advice. No unnecessary words.

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

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

Given a single required parameter, high schema coverage, and presence of an output schema, the description covers purpose, usage constraints, and behavioral details. The additional guidance on identifying the session owner adds completeness. No gaps remain.

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

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

Schema coverage is 100% with a clear description for 'handle'. The description adds minimal extra context by mentioning 'completed handoffs', but does not significantly enhance understanding 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 returns terminal session start result, lean result summary, and audit events. It distinguishes itself from siblings by emphasizing it is read-only and does not sign/submit, providing a specific verb and resource.

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

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

Explicitly states the tool is for read-only preparation/result lookup only and that the MCP does not sign, submit, or execute. Provides a specific alternative workflow (users sign locally) and gives guidance on identifying the session owner, making it clear when to use this tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds no behavioral details beyond those, but does not contradict annotations. Adequate given annotation coverage.

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

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

Two sentences: first states purpose with examples, second gives specific parameter usage. Front-loaded, no wasted words.

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

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

Description covers purpose, usage, and key parameter. Owner parameter not elaborated but optional. Output schema handles return value. Context from siblings and annotations is sufficient.

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

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

Schema covers 100% of parameters with descriptions. Description adds concrete example for windowHours (336 hours for 2 weeks), providing practical context beyond schema's generic description.

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

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

Description specifies verb (get) and resource (XDaLa session statistics) with concrete examples (success/failure counts, average duration). Distinguishes from sibling tools focused on individual sessions or listings.

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?

Clearly states when to use ('when user asks for aggregate XDaLa session statistics') and provides parameter hint ('For last 2 weeks, pass windowHours=336'). Does not explicitly exclude alternatives but context with sibling tools implies differentiation.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. Description adds context of aggregation behavior without contradicting 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 purpose and example. No redundant information, every part is valuable.

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

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

Output schema exists, so return values need not be described. Description covers usage context and examples well. Could mention optional nature of parameters, but implied by example.

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. Description provides example usage showing how to combine windowHours and bucket but does not add significant new semantic meaning beyond schema.

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

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

Description clearly states it provides XDaLa sessions over time with specific examples like 'sessions per day' or 'monthly session trend'. Distinguishes from siblings by focusing on time series aggregation.

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

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

Explicitly tells when to use ('when the user asks for XDaLa sessions over time') and gives concrete example with parameter values. Lacks explicit exclusions or alternatives but provides strong 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?

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses the data source (Explorer PGRO via MCP gateway), the per-owner/session deduplication behavior (first matching receipt), and the return type (compact scalar statistics). This is rich behavioral context not present in the annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and every clause contributes new information: data source, selection rule, and output format. No wasted words.

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

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

With rich annotations, an output schema, and 100% schema coverage, the description need not explain return structure. It adds valuable context about source, selection logic, and intended use. However, it does not mention when to prefer this tool over sibling payload-stats tools, leaving a small completeness gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds clarity around 'per owner/session' grouping, but it does not meaningfully explain parameters like windowHours or limit, leaving the schema to carry that burden (where windowHours description is tautological).

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

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

The description clearly states the tool reads an indexed history of payload values for starting a specific XRC-729 OSTC entry step, and returns compact scalar value statistics for UI pickers. It distinguishes itself from sibling payload stats tools by emphasizing the start-payload history and UI picker use case.

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

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

The description implies usage for UI pickers and provides operational details like reading Explorer PGRO and selecting the first receipt per owner/session, but it never explicitly states when to use this tool over alternatives such as get_xdala_payload_field_value_stats or get_latest_session_payload.

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 description does not need to repeat safety. The description adds value by specifying the types of statistics available (valid, invalid, failed, gas totals), but does not detail output format or pagination.

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 purpose, zero wasted words. 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 4 optional parameters and an output schema, the description is sufficient to guide usage. It covers the purpose and typical queries, though more detail on parameter interactions could improve completeness.

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

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

Schema coverage is 100% with descriptions for all 4 parameters. The description adds no additional parameter meaning beyond the examples, so it meets the baseline but does not exceed.

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 explicitly states the tool returns 'step-level XDaLa statistics' and gives concrete examples like 'how many steps were valid', 'invalid steps', etc. It clearly distinguishes from siblings like get_xdala_session_stats by focusing on step-level.

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

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

States 'Use this when the user asks for step-level XDaLa statistics', providing clear context. Does not explicitly mention when not to use or alternatives, but the examples cover common queries.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds minimal new behavioral info beyond referencing an underlying RPC call.

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, clear sentence with no wasted words. It efficiently communicates the tool's purpose.

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

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

Given zero parameters and an output schema, the description is complete. It tells the agent what information is retrieved, which is sufficient for selection and 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?

Input schema has no parameters, so baseline is 4. The description confirms the output is circulating supply, which is appropriate for a parameterless tool.

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

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

The description clearly states the tool retrieves circulating supply information, using a specific verb and resource. It is distinct from sibling tools, which focus on different data.

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

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

No guidance is provided on when to use this tool versus alternatives. The description simply instructs to use it, without 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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Description adds no further behavioral details (e.g., no mention of response structure or rate limits), but 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?

Single sentence that directly states the tool's action. No wasted words; front-loaded with the verb 'retrieve'.

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 zero parameters, rich annotations, and an existing output schema (not shown but referenced), the description sufficiently explains the tool's purpose. No additional context 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?

No parameters exist, so schema coverage is 100% by default. Description does not need to explain parameters. Baseline for zero parameters is 4.

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 uses verb 'retrieve' and resource 'XGR core protocol addresses', and distinguishes itself by referencing the specific RPC method 'xgr_getCoreAddrs'. Among many siblings, this tool's purpose is unambiguous.

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

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

Description implies usage context ('Use this to retrieve...') but does not explicitly state when to use versus alternatives or when not to use. Lacks guidance on preconditions 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, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the agent knows this is a safe read operation. The description adds minor context ('canonical Markdown documentation') but does not elaborate on error handling or exact behavior beyond what the schema provides.

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 (10 words), front-loaded with the verb 'retrieve', and contains no unnecessary 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?

Given the simple parameter (enum), annotations covering safety, and presence of an output schema, the description is mostly complete. It could optionally clarify that the returned documentation corresponds to the specified topic, but the current version is sufficient.

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 adds meaning beyond the schema: it specifies the output is Markdown documentation and clarifies that the topic is XGR/XDaLa-related. Schema coverage is 100% with an enum, but the schema description for 'topic' is tautological ('Value for the topic parameter'), so the tool description compensates.

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

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

The description clearly states the action ('retrieve') and resource ('canonical Markdown documentation for an XGR/XDaLa topic'). It distinguishes from sibling tools like 'list_xgr_docs' which lists all topics, and other get_ tools that retrieve specific standards or references.

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. No explicit 'when to use' or 'when not to use' is given, and no mention of related sibling tools.

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