Decision Anchor

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

No annotations provided, so the description carries the burden. It mentions the tool costs DAC and returns anomaly results, but does not disclose whether it is destructive, authentication requirements beyond the auth_token parameter, or rate limits. The payment flow is partially described in the schema but not elaborated in the description.

Agents need to know what a tool does to the 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: the first states the action, the second summarizes the output. No redundant words. Front-loaded with key information.

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

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

Given no output schema, the description at least names the 5 dimensions. However, it does not specify the response structure or how to interpret the results. With 4 parameters well-described in schema, it is mostly complete but could benefit from more output details.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add semantic value beyond the schema. It mentions output dimensions but no additional parameter context.

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

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

Description clearly states the tool compares a decision against an accumulated pattern and returns band_position for 5 specified dimensions. It also mentions it costs DAC, which is distinctive. It is distinct from siblings like 'get_environment_anomaly' and 'observe_pattern'.

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

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

No explicit guidance on when to use this tool versus alternatives. The description does not state when not to use or mention alternative tools like 'get_environment_anomaly' or 'observe_pattern'. Usage context is implied but not clarified.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the external settlement effect: 'the agreed scope is fixed outside both parties' own logs,' and clarifies that the integrity hash and timestamp are created at declaration time, so they are not inputs. This goes beyond a simple 'confirms decision' and gives useful context about immutability and external anchoring.

Agents need to know what a tool does to the 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 four sentences, front-loaded with the key usage context, and every sentence contributes new information. It avoids repetition of schema details (like auth_token) and stays focused on workflow, effect, and prerequisites. No waste.

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

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

For a simple two-parameter tool with no output schema, the description is nearly complete. It explains the purpose, the prerequisite (create_decision), the effect (settled external record), and the timing (after action execution). It doesn't mention error handling or return values, but for a straightforward confirmation action, this 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 coverage is 100%, providing the baseline of 3. The description adds meaning by emphasizing 'confirm requires only the dd_id,' clarifying that the only substantive input is the decision ID. It also explains that hash/timestamp are not parameters, preventing confusion. This disambiguates the role of dd_id 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 the tool's function: 'Confirm a pending decision: marks the anchored declaration as settled.' It also explains the purpose in the broader workflow: 'Use after create_decision to settle the anchored boundary as an external record.' This specific verb+resource pair is distinct from siblings like get_decision or list_decisions, which are read-only.

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?

Explicit when-to-use guidance is provided: 'Use after create_decision' and 'Call this after the action described in the DD has been executed.' This clearly positions the tool relative to its sibling create_decision. However, it doesn't explicitly mention alternatives or when not to use, such as if the decision is already confirmed.

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?

Without annotations, the description carries the burden, and it delivers useful behavioral context: the decision is tamper-evident, anchored, and appended to a record trajectory checkable against DA's external entry. It also surfaces default EE/preset cost behavior and points to a pricing endpoint, though it does not deeply cover all side effects such as error handling or exactly what the response returns.

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

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

The description is compact for a 24-parameter tool and front-loads the key decision trigger. Slight redundancy exists around 'record' and 'decision', but no sentence seems wasted; the pricing and default discussion earn their place by explaining aggregation of many parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 complex creation endpoint with 24 parameters, the description gives enough shared context: scope, timing, sibling distinction, and EE/pricing defaults. It does not describe the output shape, which is likely significant because no output schema is present, but the description nevertheless sets up an agent well for correct invocation.

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

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

Schema description coverage is high, so the baseline is 3; the description adds extra value by explaining how the four EE axes interact as a preset, what 'omitting EE axes' means in practice, and that EE_standard costs 45 DAC while EE_basic costs 10 DAC. This helps an agent understand the decision-relevant implications of parameters without opening the pricing endpoint.

Input schemas describe structure but not intent. Descriptions should explain 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 concrete trigger ('an action crosses an external boundary: payment, delegation, or agreement') and a clear primary action ('Record a tamper-evident decision'). It also distinguishes itself from the sibling propose_bilateral by stating that this route is for self-declared decisions while counterparty declarations belong to the other endpoint.

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

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

The description explicitly states when to use this tool and when not to: use it for self-declared decisions, and use propose_bilateral when a counterparty is involved. It even gives timing guidance ('before you execute, or after a decision you have already made'), so an agent gets clear contextual boundaries.

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

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

With no annotations, the description carries the full burden of disclosure. It shares that content is not recorded and that billing modes are selectable, which is useful. However, it omits session lifecycle details, such as how to exit the session or what happens when it ends, and does not explain billing implications beyond the mode names.

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

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

The description is three concise sentences, each adding distinct information: the state's purpose, content recording behavior, and billing options. It is front-loaded with the primary action and contains no redundant or tangential details.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description covers the core behavior and key constraints. However, it does not mention how to leave the session or the session's duration, which are relevant for a session-creating tool, even with a sibling 'exit_ise_session' available.

Complex tools with many parameters or behaviors need more documentation. 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 provides 100% coverage for both parameters, including a clear enum for payment_mode. The description mentions billing choices but adds no additional meaning beyond what the schema already specifies, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: entering a non-productive state. It distinguishes from siblings like create_sdac_session by explicitly characterizing the state as requiring no decision, execution, or accountability. The tool name 'create_ise_session' aligns with the described action.

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 for when the tool is appropriate: when no decision, execution, or accountability declaration is needed. It implies usage for idle or non-productive periods, but does not explicitly mention alternatives or when not to use it, leaving some room for inference.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions cost savings and simulation but does not explain what starting a session entails, any side effects, credit consumption, or reversibility. For a session-creating tool, this lack of transparency is a significant gap.

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

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

The description is extremely concise, using two short sentences to state the primary action and its value proposition. There is no unnecessary detail or repetition of schema information.

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

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

For a one-parameter tool, the description covers the core purpose and usage context. However, it does not explain the session lifecycle or relationship to sibling tools like end_sdac_session or run_sdac_trial. The lack of an output schema also leaves return values unspecified, but this is a minor gap for such a simple 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?

The schema already provides a full description for the sole parameter auth_token, and the tool description adds no additional parameter information. Since schema coverage is 100%, 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 'Start a simulation session' with a specific verb and resource. It also distinguishes itself from real decision creation by mentioning 'before creating real decisions', making the tool's purpose distinct from siblings like create_decision.

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 that this tool is for testing EE combinations at a fraction of the cost before committing to real decisions, implying its use as a low-cost simulation alternative. However, it does not explicitly name alternative tools or state exclusions, which would make it a 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?

Since no annotations are provided, the description carries the behavioral transparency burden. It discloses that the session is ended, costs are settled, and session creation is blocked until closure. It does not mention repeated-call behavior or irreversibility, but it is reasonably transparent for a simple session-ending tool.

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

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

The description is brief, with each sentence serving a clear purpose: the action, the usage signal, and a key behavioral consequence. No filler or redundant content.

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

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

The tool is simple enough that this description, combined with a fully documented schema, gives strong guidance. The main gap is lack of details about what happens if the session is already closed, but that does not severely impede the agent.

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

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

The input schema covers 100% of parameters, including a thorough explanation of the payment_signature challenge flow. The description adds little parameter-level meaning beyond what the schema already 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 uses a specific verb ('End') and resource ('a simulation session'), and adds 'settle its accumulated cost' to clarify the full semantic. It clearly distinguishes this from sibling tools like create_sdac_session and get_sdac_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?

It gives direct usage instruction: 'Call this when you are done.' It also provides a concrete consequence of not doing so, namely create_sdac_session returns 409 SESSION_EXISTS. It doesn't explicitly list alternatives, but the context is clear.

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

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

With no annotations, the description carries the transparency burden. It mentions the 409 condition and that the session is 'settled', but does not disclose side effects like irreversibility or whether authorization is required beyond the auth_token parameter.

Agents need to know what a tool does to the 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, both directly relevant. The first states the action, the second clarifies when to call and the consequence of not doing so. No redundant or filler content.

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

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

The description covers the purpose, usage timing, and a key behavioral consequence (409 error). Since there is no output schema, return values are not required. The schema handles parameter semantics, so the description is sufficiently complete for the tool's context.

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

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

The input schema already provides detailed descriptions for both parameters (auth_token and payment_signature), achieving 100% coverage. The description adds no additional parameter-specific meaning, so it stays at the baseline for high schema coverage.

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

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

The description explicitly states the tool's function: 'End your active ISE session and settle it.' It clearly differentiates from sibling tools like create_ise_session and end_sdac_session by specifying 'ISE 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?

It provides direct usage guidance: 'Call this when you are done.' Additionally, it references the consequence of not using it (create_ise_session returns 409), which helps the agent decide when to invoke 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?

With no annotations provided, the description carries the full burden. It discloses that the tool is paid, requires an x402 payment, and provides a two-step process (omit payment_signature to get a challenge, then sign and call again). It also states that Decision Anchor never holds keys or signs on behalf of the user, which is important behavioral context. This is substantial transparency beyond just 'view profile.'

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

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

The description is concise and front-loaded with the core purpose. It adds necessary context (payment, trial coverage) and the payment flow in a structured manner. No wasted words, and it clearly separates the main description from the parameter-specific guidance.

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

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

Given no output schema, the description provides a good overview of what to expect (trajectory shape, EE patterns, activity summary) but doesn't detail return format or possible errors. It adequately covers the tool's purpose, usage, and payment intricacies, but could be more complete in describing the response structure or edge cases. Still, it's quite comprehensive for its complexity.

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

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

The schema description covers 100% of parameters, but the description adds valuable context about payment_signature: it's optional on first call, required for paid calls, and explains the challenge-response flow. It also clarifies that agent_id is the agent to observe, though this is already in the schema. The description compensates for the payment flow nuance beyond the schema's 'Optional x402 payment payload.'

Input schemas describe structure but not intent. Descriptions should explain 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: viewing an agent's decision profile, specifically mentioning trajectory shape, EE patterns, and activity summary. It also specifies the context (as observed through ARA) and a critical constraint (paid via x402, not covered by Trial). This distinguishes it from sibling tools like confirm_decision or create_decision.

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

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

The description implies when to use this tool: when you need to observe an agent's decision profile via ARA, and notably mentions a prerequisite or restriction: it's paid via x402 and not covered by Trial. However, it doesn't explicitly contrast with alternatives like observe_pattern or get_decision, which could be relevant for similar purposes, so it 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?

With no annotations provided, the description carries the full transparency burden. It does add meaningful context by disclosing the two-component balance structure (External/funded vs Earned from tool sales), which goes beyond the tool name. However, it doesn't address response size, potential latency, or authentication failure behavior, though these are less critical for a simple read-only getter.

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

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

Two short sentences, front-loaded with the action verb and primary object. The second sentence ('Know what you have before you decide what to spend') is slightly motivational filler but does convey the use-before-spending context. Overall economical and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 getter with 1 fully-documented parameter and no output schema, the description sufficiently conveys what the tool reveals (both balance components). Complexity is low, and while it could theoretically mention return format, the absence is not a major gap given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. 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% (the single auth_token parameter is already fully documented in the schema), so the description doesn't need to compensate. Per the baseline rule, this earns a 3 since the schema does the heavy lifting and the description adds nothing param-specific.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Check') with a clear resource ('your current DAC balance') and reveals meaningful scope detail (two balance types: External and Earned). It's clear and self-contained, though it doesn't explicitly distinguish itself from siblings like get_dac_ur.

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

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

The phrase 'Know what you have before you decide what to spend' implies this should be called before spending decisions, which is a mild usage signal. However, there's no explicit when-to-use, when-not-to, or named alternatives, so the guidance is mostly implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the report is a 'detailed breakdown' and 'useful for budgeting', but it does not specify whether the report includes real-time data, historical aggregation, or any limitations (e.g., date range constraints, data availability). It also doesn't mention authentication requirements beyond the auth_token parameter, which is expected.

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

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

The description is concise, with two sentences that front-load the purpose and then add usage value. No wasted words, but it could have included a bit more behavioral detail in the same length, hence not a 5.

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

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

The tool is relatively simple (3 params, no output schema). The description covers the purpose and usage, but lacks behavioral context like data update frequency, potential volume of data, or any response format hints. Given the simplicity, a score of 3 is justified; it's adequate but could elaborate on what the report does not include (e.g., real-time vs. settled data).

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

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

The input schema covers 100% of parameters with descriptions (e.g., to/from as ISO 8601 dates). The description adds the context of 'spending by service, period, and transaction type', which implies the date range is used for filtering but doesn't provide additional syntax or format details beyond the schema. Baseline 3 is appropriate as the schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain 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: 'View your DAC usage report: a detailed breakdown of spending by service, period, and transaction type.' It uses a specific verb ('View') and resource ('DAC usage report') and distinguishes it from related tools like get_dac_balance, implying the report is broader than just balance.

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

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

The description explains the usage context: 'Useful for budgeting and trajectory analysis.' This gives a clear indication of when to use the tool, but it does not explicitly mention alternatives or when not to use it. Given the tool's specificity, the context is sufficient for most cases.

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

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

No annotations are provided, so the description must carry the burden. It explicitly states what is NOT returned ('never its content'), which is a valuable behavioral detail. It also mentions return components (enums, timestamps, hash) without needing to describe format. This is good transparency for a read operation, though not exhaustive.

Agents need to know what a tool does to the 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 the purpose, and no wasted words. Every clause adds information: what, when, scope, lineage, formal shape, and explicit exclusion of content. Perfectly concise for the information density.

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

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

For a simple read tool with 2 params and no output schema, the description is effective. It explains what the output contains (declared, when, scope, lineage, formal shape) without a schema. It could mention error cases or auth requirements, but auth_token param covers auth. Given the tool's simplicity, it's quite 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 covers 100% of parameters, and dd_id is described simply as 'The DD ID to retrieve'. The description adds context about the ID being a 'specific decision record' and hints at lineage, which adds slight value. With full schema coverage, this is a solid 4, as the description goes a bit beyond the bare 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 retrieves a specific decision record by ID, describes what it returns (declaration, timing, scope, lineage, formal shape), and distinguishes from siblings like list_decisions and get_decision_metadata_distribution. The verb 'retrieve' combined with specific resource and scope is precise.

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 a lookup-by-ID use case, which is clear context. However, it doesn't explicitly state when not to use it or mention alternatives like list_decisions for browsing. Maybe there is no explicit exclusion, but the purpose statement makes the usage obvious, so a 4 is fair.

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

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

With no annotations, the description carries the full burden and discloses a key behavioral trait: it requires a paid observation (3 DAC) and returns 402 with payment terms first, implying a two-step flow. It does not detail what happens after successful payment, but the payment behavior is a significant transparency win.

Agents need to know what a tool does to the 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 each sentence earns its place. No fluff or repetition.

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

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

Given the paid nature and lack of annotations/output schema, the description adequately covers the payment flow and scope. It could be more explicit about what the successful response contains, but the tool is simple and the 402 flow is explained well.

Complex tools with many parameters or behaviors need more documentation. 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 clear descriptions for both parameters (auth_token and payment_signature). The tool description's mention of 'Paid observation' adds context around the payment_signature parameter, but it doesn't supplement the schema's parameter descriptions beyond that, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb ('Observe') and resource ('decision metadata distribution'), enumerating the exact breakdown fields (decision_class, target_class, decision_trigger, human_involvement) and scope ('your branch-1 decisions'). This distinguishes it from sibling tools like get_self_classification_distribution.

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 about the paid nature and the 402 payment flow, which is essential usage guidance. However, it does not explicitly contrast with alternatives or state when not to use the tool, so it falls short of a 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?

No annotations provided, so description carries full burden. Lists topics covered, but does not mention response format, caching, or access restrictions. Adequate for a read-only tool with no parameters.

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

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

Two sentences, front-loaded with purpose, includes a bullet-like list of topics. 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 zero parameters and no output schema, the description fully explains the tool's purpose and scope. 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?

No parameters exist; schema coverage is 100%. Baseline of 4 applies as description adds no param info but is unnecessary.

Input schemas describe structure but not intent. Descriptions should explain 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 'Retrieve the full agent guide for Decision Anchor' with specific verb and resource. Easily distinguished from sibling tools like create_decision or confirm_decision.

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 recommends 'Read this before using DA,' giving clear context for when to use. No exclusions but the directive serves as strong 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?

With no annotations provided, the description carries full burden. It discloses key behavioral traits: de-identification, k-anonymity threshold (k>=10), and the fact that it costs DAC. However, it doesn't disclose other variables that might be relevant to a full understanding of the tool's behavior—like pagination limits or how deep the per-dimension counts go. The 'Costs DAC' note is a useful throughput/rate-limit hint that goes beyond the schema.

Agents need to know what a tool does to the 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, all dense with meaning: what it does, privacy properties, and cost. Could perhaps add one note about whether it requires an environment context, but overall it's tight and front-loaded with the most critical 'what does this do' information first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 a clear sibling distinction (anomaly vs. evidence report, environment observation), the description does enough by teaching what's special (k-anonymity, de-identified) without restating schema internals. It explains the DAC cost, the privacy guarantee, and the unit of analysis (across the population) well. A more complete description might warn about the DAC cost or mention that it's safe for production queries, but it's largely complete for an agent to use appropriately.

Complex tools with many parameters or behaviors need more documentation. 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 includes a payment/challenge flow, yet the description adds a high-level semantic: it's an observation aggregate across the population (not per-session). The description provides mental model context, especially for the 'dimension' parameter (returned distribution per dimension) and 'payment_signature' (the challenge flow is described in the schema; description adds 'De-identified, k-anonymity' context). Since the schema fully documents each param, the description's aggregation of them into a conceptual model earns above 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 starts with a specific verb+resource pairing ('Observe environment-level anomaly distribution') and clearly explains what the tool does: returns within_band/outlier counts per dimension across the population. It distinguishes itself from the sibling tool 'observe_environment' by specifying the anomaly distribution angle and the per-dimension breakdown across the population.

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 clearly signals this is an environment-level aggregate tool (vs. individual or decision-level queries), which helps narrow when to use it. It also provides implicit exclusions by specifying what this tool is NOT for (de-identified aggregates, not detailed records). However, it doesn't explicitly name an alternative sibling tool or provide when-not-to-use conditions, which would elevate it to a 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?

With no annotations, the description must carry transparency. It discloses that the tool 'Costs DAC', a behavioral side-effect, and states the report is 'structured for external audit review'. It does not explicitly mention read-only nature or side effects beyond cost, but for a GET-style tool this is acceptable. It adds context beyond the schema by highlighting cost and audit purpose.

Agents need to know what a tool does to the 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, then lists report contents, and ends with the cost note. No wasted words, easy to scan, and every sentence adds value.

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

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

For a report-generation tool with no output schema, the description adequately conveys what the report contains (metadata, EE resolution, responsibility declaration) and the cost implication. It lacks details on output format (e.g., JSON, PDF) but that is not essential given the tool's nature. Overall, it is sufficiently complete for an agent to understand what it returns.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description does not add any additional parameter meaning beyond what the schema already provides. The payment flow is explained in the schema itself, not the description. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states this tool generates an 'external-audience evidence report' for a decision, which is a specific verb+resource. It distinguishes from sibling tools like get_decision by focusing on external audit context, and mentions specific contents (metadata, EE resolution, responsibility declaration).

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 it is for external audit reporting of decisions, and notes it 'Costs DAC'. However, it does not explicitly state when to use this over other get_* tools, nor provide exclusions or alternatives. Some guidance is implied via the external-audit wording, but not explicit.

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

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

With no annotations provided, the description carries the transparency burden. It states the operation is a read-only check ('Check whether'), and notes it is 'Free', adding cost behavior. It does not explicitly say it modifies nothing, but 'Check' strongly implies no side effects, and the free mention adds useful context.

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

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

Two sentences, front-loaded with the primary function. Every part adds value: the purpose, the return information, the cost, and the relationship to exit_ise_session. No wasted words.

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

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

For a simple read-only tool with one parameter and no output schema, the description explains the main outputs (elapsed time, billing mode) and its practical purpose. It doesn't mention error behavior or exact response format, but given the low complexity, it is reasonably complete.

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

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

Schema coverage is 100%, with auth_token described as 'Your DA agent auth token'. The description adds no additional meaning to the parameter, so baseline 3 is appropriate since the schema already fully documents it.

Input schemas describe structure but not intent. Descriptions should explain 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 for an active ISE session and provides elapsed time and billing mode. It also differentiates from siblings by explicitly tying it to exit_ise_session, making its 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 gives a specific use case: 'Use this to find out what exit_ise_session will close.' This implies when to use it (before exiting) and provides context, though it does not explicitly state when not to use it or list alternatives beyond the implicit ISE session context.

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

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

With no annotations, the description must carry the burden. It mentions 'Free' (cost) and specifies the return fields. However, it doesn't explicitly state that it's read-only or that it has no side effects. It also doesn't mention error behavior (e.g., session not found) or any rate limits. The term 'look up' implies a query, but this is not explicitly disclosed.

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

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

Two sentences, front-loaded with the primary purpose. Every word adds value: the return fields, the cost implication ('Free'), and the usage hint. No redundancy or fluff.

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

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

Since there is no output schema, the description appropriately lists the return items (status, trial count, accumulated cost). It also gives a practical use case and cost info. It doesn't mention error handling or response format, but for a simple lookup this is acceptable. It is complete enough for an agent to select and 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 both auth_token and session_id described. The description adds no additional parameter details beyond what the schema provides; 'by ID' simply aligns with session_id but adds no new meaning. 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 'Look up' and identifies the resource 'simulation session by ID'. It lists exactly what it returns: status, trial count, accumulated cost. It is clearly distinct from siblings like create_sdac_session and end_sdac_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?

It states a specific use case: 'Use this to see what end_sdac_session will settle.' This gives clear context for when to use it, but it doesn't explicitly mention when not to use it or alternative tools (though it hints at end_sdac_session). No exclusions are provided.

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

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

No annotations are provided, so the description must disclose behavioral traits. 'Observe' implies read-only, but no information is given about side effects, authorization needs beyond the generic auth_token, or performance characteristics.

Agents need to know what a tool does to the 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 superfluous words. It is appropriately sized for a simple tool, though slight expansion could improve 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?

The tool has no output schema, but the description does not explain the return format (e.g., what the distribution looks like, keys, values). For a simple tool, agents need to know what to expect from the response.

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

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

Schema coverage is 100% (only auth_token, which is described). The description does not add additional meaning to the parameter beyond what the schema provides, so baseline score applies.

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

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

The description clearly states the verb 'Observe' and the resource 'self_classification distribution' with scope 'across your branch-1 decisions.' It distinguishes from siblings like get_decision_metadata_distribution and list_classifications by focusing on self_classification specifically, though 'self_classification' is not defined.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., get_decision_metadata_distribution) or any prerequisites or conditions for use.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Check' implies a read-only action, but the description does not explicitly state it has no side effects, requires authentication (beyond the param), or whether it might fail if no trial is active. It adds minimal context beyond the purpose, missing details like rate limits or data volatility.

Agents need to know what a tool does to the 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 elegant and efficient: two sentences. The first sentence front-loads the purpose and the details returned; the second adds valuable contextual information about the trial allowance (500 DAC for 30 days). Every sentence earns its place, with no redundancy or extraneous 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 the tool's simplicity (one parameter, no output schema, no annotations) the description is essentially complete. It conveys what the tool does and what it returns in terms of content (remaining DAC, days left, usage). The only slight gap is that it doesn't explicitly state what happens if the trial has ended or is not active, but this is a minor omission for a low-complexity tool.

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

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

The input schema already provides full coverage (100%) with a description for the single 'auth_token' parameter: 'Your DA agent auth token'. The tool description adds no additional information about the parameter, but since schema coverage is complete, the baseline of 3 is appropriate. The description does not reinforce or supplement the schema's parameter documentation.

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

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

The description clearly states the purpose: 'Check your trial account status: remaining DAC, days left, and usage so far.' This specifies the verb (check), the resource (trial account status), and enumerates the exact details provided. It distinguishes from siblings like get_dac_balance (which likely shows overall DAC) and get_agent_profile (profile info), 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 implies usage when you want to know about a trial, but it does not explicitly tell when to use it versus alternatives like run_sdac_trial or get_dac_balance. It provides context ('Trial gives you 500 DAC for 30 days') but no explicit when-to-use or when-not-to-use guidance, nor does it mention any exclusions or prerequisites.

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

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

No annotations exist, and the description only implies a read operation without disclosing potential side effects, authentication requirements beyond what schema says, or any behavioral nuances.

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

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

Extremely concise two-sentence description that front-loads the purpose and provides actionable usage guidance.

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

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

Adequate for a simple list tool but lacks any mention of the response structure or format, and no output schema is provided to compensate.

Complex tools with many parameters or behaviors need more documentation. 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 parameter description fully, but the tool description adds no additional meaning or context to the auth_token parameter.

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

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

The description clearly states the tool lists available self_classification categories with a specific scope ('operator base + owner-registered') and relates it to create_decision usage.

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 mentions when to use (for create_decision with content_inclusion_flag=1) but does not name alternative tools in case of other needs.

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

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

With no annotations, the description must disclose behavior. It states 'list' (read-only) but fails to mention pagination, filtering behavior, or error conditions for auth_token. The presence of limit/offset params in the schema is not reflected in the description.

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

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

Two short sentences, front-loaded with the key action. The second sentence adds some motivational context but is not essential. Overall well-sized.

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

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

With 5 parameters and no output schema, the description is insufficient. It does not explain return format, pagination behavior, or how 'your' records are scoped. The agent would lack context for correct invocation.

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

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

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

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

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

The description clearly states 'List your decision records' with a specific verb and resource. However, it does not explicitly distinguish from sibling tools like get_decision, which retrieves a single record; the differentiation is implied but not stated.

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 given on when to use this tool versus alternatives (e.g., get_decision, confirm_decision). There are no prerequisites or context for when this tool is appropriate.

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

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

No annotations are provided, so the description bears full burden. It only states 'browse' and 'discover', omitting any behavioral traits like read-only nature, pagination behavior, or side effects. This is insufficient for an agent to understand the tool's safety profile.

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

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

The description is extremely concise with two short sentences, no redundant information, and is efficiently front-loaded.

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

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

For a listing tool with 4 optional parameters and no output schema, the description fails to explain pagination, default behavior, or response fields. This leaves the agent guessing about how to use parameters effectively.

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

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

Schema coverage is 100%, so each parameter has a description. The tool description adds no additional meaning beyond 'marketplace' context, which is already implicit from the name. 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 'browse' and 'discover' clearly indicating the tool lists marketplace tools, distinguishing it from sibling tools like list_classifications or list_decisions. However, it could be more specific about the information returned (e.g., tool metadata, pricing).

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

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

No guidance is provided on when to use this tool versus alternatives such as list_classifications or list_decisions. The description does not mention any 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?

With no annotations, the description carries the burden of disclosure. It provides meaningful behavioral context: costs 1 DAC, requires auth_token, is paid via x402, and has a versioning note (formerly free). It doesn't explicitly state return format or side effects, but 'observe' implies a read-only 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 two sentences, front-loads the purpose, and then costs/requirements. Every sentence adds value with no redundancy; it is compact yet informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 and lack of output schema, the description covers purpose, cost, auth, payment, and trial exclusions. The payment challenge flow is explained in the schema parameter, so overall context is sufficient, though a brief mention of return format or the two-call challenge in the main description would improve completeness.

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

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

Schema description coverage is 100%, so the baseline is 3. The main description adds only 'requires auth_token' (already in schema as required) and payment context, but does not meaningfully enhance parameter semantics beyond the schema's own detailed payment_signature explanation.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Observe') and resource ('aggregate environment statistics') with concrete details (active agents, total decisions recorded, activity density). It distinguishes itself from siblings like observe_pattern and get_environment_anomaly by focusing on aggregate stats.

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 clearly states the cost (1 DAC), required auth_token, payment method (x402), and that Trial does not cover ARA observation. This provides clear context for when to use the tool, though it doesn't explicitly name alternatives or state 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?

Since no annotations are provided, the description carries the full burden and does well by disclosing cost (1 DAC), authentication needs (auth_token), payment method (x402), and a critical restriction (Trial does not cover ARA observation). This is valuable behavioral context beyond a simple one-liner.

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

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

Two sentences, no fluff. Every word adds value, covering purpose, cost, auth, and payment context in under 40 words.

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

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

For a tool with no annotations and no output schema, the description covers the essential behavioral aspects: what it does, what it costs, auth requirements, and payment limitations. Additional info like return format would be nice but is often not critical for a straightforward observation tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific details beyond what the schema already contains, but it does add cost/trial context that helps interpret the payment_signature flow.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Observe') and clearly defines the resource ('pattern-level EE distributions and action-type breakdowns across agents'). It is specific and distinct from the sibling tool 'observe_environment', which appears to be environment-focused.

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

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

The description provides usage context by mentioning cost, auth requirements, and trial limitations, but it does not explicitly state when to prefer this tool over alternatives like 'observe_environment', nor does it give explicit when-not-to-use 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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does disclose key behavior: it creates a bilateral decision record and waits for counterparty acceptance, and it emphasizes that agreement is required before anchoring the boundary. It could add failure and timeout behavior, but the main side effects are more transparent than typical in low-annotation tools.

Agents need to know what a tool does to the 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 tightly written with the 'when to use' trigger front-loaded, followed by illustrative use cases and a clear mechanism sentence. There is no filler or redundancy; all three sentences earn their 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 21-parameter tool with no annotations and no output schema, it covers the most important context: the bilateral requirement, the waiting behavior, and likely use cases. It could say a little more about what happens after acceptance or on failure, but the essential operational context is present and coherent.

Complex tools with many parameters or behaviors need more documentation. 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 explains most parameters. The description adds use-case context but does not need to restate parameter details. This meets the baseline expected when the schema carries the semantic weight.

Input schemas describe structure but not intent. Descriptions should explain 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: propose a bilateral agreement, create a DD with declaration_mode 'bilateral', and wait for counterparty acceptance. It also identifies concrete use cases like payment splits and task delegation, which distinguishes it from the sibling tools such as create_decision or confirm_decision.

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 when to use the tool: when two agents need to fix a shared boundary and both must agree. It gives concrete examples of appropriate scenarios. It does not explicitly name when not to use it or point to an alternative sibling tool, but the trigger condition is still 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?

No annotations are provided, so the description carries the burden. It does disclose meaningful behavior: payment is via x402, the tool creator earns DAC, and trial coverage is excluded. However, it does not mention irreversibility, refund policy, or the two-call challenge flow, which would be valuable for a financial mutation tool.

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

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

The description is two terse, front-loaded sentences with no filler. Every clause adds useful information: the action, the consequence, the payment mechanism, and a trial caveat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 small tool with a detailed schema, the description adequately frames the purpose, payment rail, and trial caveat. It does not explain success return values, but the payment_signature parameter description already covers the challenge-response behavior, so the tool remains usable and well-contextualized.

Complex tools with many parameters or behaviors need more documentation. 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 the schema richly documents all four parameters including the complex payment_signature flow. The description itself adds no parameter-level meaning, but the schema carries the full burden, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb+resource: 'Purchase a tool from the marketplace.' It further distinguishes the tool by noting the creator earns DAC and that payment is made via x402, making the purpose unambiguous and distinct from sibling tools like list_tools and register_tool.

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

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

The description clearly positions this as the paid purchase path and explicitly states 'Trial does not cover this route,' providing a clear exclusion. It does not name an alternative tool, but the purchase context is otherwise clear and intuitive.

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

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

With no annotations, the description must fully convey behavior. While it notes trajectory accumulation and observability, it omits side effects (e.g., idempotency, entity creation), authorization, and consequences of multiple registrations.

Agents need to know what a tool does to the 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) and front-loaded with the key action. However, it omits critical details, balancing brevity with inadequacy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 sibling tools and optional parameters, the description is incomplete. It fails to specify the return value, confirm registration, or clarify the agent's role, leaving significant gaps.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, meeting the baseline for high coverage.

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

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

The description states the verb 'register' and the resource 'in this environment', making the purpose clear. It adds context about decision accumulation and observability, but does not explicitly distinguish from sibling tools like 'register_tool'.

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

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

No guidance is provided on when to use this tool versus alternatives, prerequisites, or whether it should be called initially. The description lacks any 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?

No annotations are provided, so the description must disclose behavioral traits. It mentions the financial aspect (earning revenue) but does not disclose any side effects, such as creating a permanent listing, potential fees, approval requirements, rollback options, or what happens on confirmation. For a marketplace publish action, more detail on side effects and prerequisites (beyond schema) is expected.

Agents need to know what a tool does to the 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 concise sentences: first states the action (publish to marketplace), second clarifies the pricing and revenue model. It is front-loaded with purpose and contains zero fluff or redundant repetition.

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

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

With no output schema and no annotations, the description leaves significant gaps. It does not mention what the tool returns upon success, error scenarios, or steps like approval or validation. It also does not explicitly mention the requirement for ARA connections (though schema states it). The description explains the core action but not the full workflow or expectations, making it incomplete for a tool with 6 parameters and no output schema.

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

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

Schema covers all parameters with 100% description coverage, so the baseline is 3. The description adds minimal new meaning beyond the schema; it mentions 'Set a price in DAC' which maps to price_dac, but it doesn't clarify auth_token or ara_connections further. The schema already explains these parameters adequately, so no compensation 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?

The description clearly states the tool's purpose: publishing a user-built tool to a marketplace, setting a DAC price, and earning revenue from purchases. It uses a specific verb ('Publish') and resource ('tool to the marketplace'), effectively distinguishing it from sibling tools like purchase_tool or list_tools.

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

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

The description implies usage when the agent has built a tool to sell, by saying 'a tool you built'. It does not explicitly mention alternatives or when-not-to-use, but the context makes it obvious this is for registration, not purchasing or listing. It provides clear context 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?

With no annotations, the description carries the full burden. It discloses that the call is free, does not create a real record, and affects the settlement amount via a formula. This is transparent about side effects, though it doesn't mention rate limits or auth requirements.

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

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

The description is three concise sentences with no redundant information. It is well-structured and directly addresses purpose, behavior, and cost implications.

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

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

Given there is no output schema, the description explains what is returned (DAC) and the side effect on settlement. It is complete for the tool's intended use, though it could mention potential errors or limitations.

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

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

Schema coverage is 100% (all 9 parameters have descriptions). The tool description adds overall context about simulation and pricing but does not elaborate on individual parameters, so it stays at baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: it prices an EE combination in a simulation without creating a real record. It distinguishes from create_decision by explicitly noting the difference, and the verb 'price' is specific.

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

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

The description implies when to use this tool (for pricing instead of actual creation) and explains the cost impact on end_sdac_session. While it doesn't explicitly list alternatives, the context is clear enough for a knowledgeable 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?

With no annotations, the description carries the burden. It discloses that the note is 'anonymous', that every field is optional, and that it's safe to skip any field. It does not disclose data persistence or limits, but the simplicity of the tool makes this sufficient.

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

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

The description is a single, concise sentence that front-loads the purpose ('Optional') and provides all necessary context without redundancy. 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 tool's simplicity, no output schema, and full schema coverage, the description is complete. It tells the agent when to use it and that all fields are optional, which is all the agent needs to know.

Complex tools with many parameters or behaviors need more documentation. 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 8 parameters with descriptions, so baseline is 3. The description adds value by emphasizing that every field is optional and can be skipped, which is not explicitly stated in the schema (though implied). This clarifies that no parameter is required.

Input schemas describe structure but not intent. Descriptions should explain 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 ('leave a brief, anonymous note') and the context ('if you've used this environment'). It is distinct from sibling tools like list_decisions or get_dac_balance, which serve different purposes.

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

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

Explicitly says 'Optional' and 'Not required to use anything here', and indicates when to use ('if you've used this environment'). It does not mention alternatives, but no sibling tool serves the same purpose, so no exclusions are needed.

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