Decision Anchor

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

Annotations declare destructiveHint=true, which would otherwise be puzzling for a comparison, and the description explains it by disclosing 'Costs DAC' — the agent learns the call consumes credit irreversibly. It also previews the return payload (band_position per dimension), which adds value. It does not detail the payment-challenge flow, though the schema's payment_signature description covers that.

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

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

Three short sentences, front-loaded with the action, then the return contract, then the cost. Nothing is redundant, and putting 'Costs DAC' last is the right ordering since it is a gating fact rather than the primary 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?

With no output schema, the description carries the return contract and does so concretely (five named dimensions with within_band/outlier values). It also surfaces the DAC cost. The remaining gap is routing guidance relative to sibling analysis tools, which keeps this from being fully complete.

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

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

Schema description coverage is 100%, so dd_id, auth_token, period_days, and payment_signature are all documented in the schema. The description adds no parameter-level meaning (e.g., which period_days value is meaningful or what the comparison window defaults to beyond the schema default), 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?

States a specific verb (compare) and resource (one of your decisions vs your accumulated pattern), and names the exact output shape: band_position with five enumerated dimensions. It is clearly distinguishable from siblings like observe_pattern or get_environment_anomaly, which do not compare a specific 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 phrase 'Compare one of your decisions against your accumulated pattern' implies context (you have a dd_id and want to know if it is an outlier), but it never states when to prefer this over observe_pattern or get_environment_anomaly, nor any prerequisites such as having a prior pattern. Usage is implied rather than 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 flag readOnlyHint=false and destructiveHint=true, and the description meaningfully builds on that by explaining the state change ('the agreed scope is fixed outside both parties' own logs') and clarifying that the integrity hash and timestamp were created at declaration time. It does not state whether confirmation is reversible, which is the one notable gap for a destructive-marked 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 core guidance is front-loaded, but the central idea is restated three times ('settle the anchored boundary as an external record', 'fixed outside both parties' own logs', 'marks the anchored declaration as settled'), which adds length without adding 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 two-parameter mutation tool with no output schema, the description covers prerequisites (create_decision, executed action), the single required input, and the resulting state change. An agent has enough to call it correctly; only post-confirmation behavior/undone state is left unstated.

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, but the description adds genuine value beyond the schema by clarifying that 'confirm requires only the dd_id' and that the hash/timestamp are not passed here. That resolves potential ambiguity about whether the caller must supply integrity data.

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 a specific verb+resource ('Confirm a pending decision: marks the anchored declaration as settled') and explicitly names the sibling it follows ('Use after create_decision'). The heavy proprietary jargon ('anchored boundary', 'anchored declaration') slightly blurs the plain purpose, but an agent can still distinguish it from create_decision and get_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 gives clear sequencing guidance: 'Use after create_decision' and 'Call this after the action described in the DD has been executed.' That routing context is strong, though it stops short of stating when *not* to use it (e.g., a decision already confirmed, or an unexecuted action).

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the write/destructive profile is covered structurally. The description goes further by disclosing the cost model (base fee plus EE-axis additions priced from current settings, returned as dac_amount/cost_breakdown), the default axis values, and that the record is trajectory-anchored and checkable against DA's external entry. It does not, however, describe the x402 challenge flow or reordering semantics, which remain schema-only.

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?

Front-loaded with the triggering condition and the routing decision, which are the highest-value sentences. The closing cost sentence largely restates pricing semantics that also live in the schema parameter descriptions, but it is one sentence and does not bury the actionable 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?

For a 24-parameter, no-output-schema mutation tool, the description covers the decision trigger, timing, the bilateral alternative, axis defaults, and where the charged amount appears. It stops short of explaining the two-phase payment challenge or the branch-0/branch-1 content distinction, but those are handled adequately in the 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 description coverage is 100% across 24 parameters, including detailed enum and preset semantics, so the schema does the heavy lifting and the baseline is 3. The description echoes the EE axis defaults and the cost implications of axis/option selection, but adds no syntax or value meaning beyond what the schema already documents.

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?

States a specific verb and resource ('Record a tamper-evident decision') and immediately scopes it against the sibling that looks similar: 'This route records self-declared decisions; a declaration that involves a counterparty is made with propose_bilateral instead.' An agent can distinguish create_decision from propose_bilateral without opening either schema.

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 names the triggering condition ('when an action crosses an external boundary: payment, delegation, or agreement with another agent') and the allowed timings ('before you execute, or after a decision you have already made'). It also names the excluded case and its alternative tool, which is exactly the when/when-not guidance the rubric reserves 5 for.

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

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

Annotations only establish non-readonly/non-destructive; the description adds genuinely useful behavior beyond that: content is not recorded and billing follows payment_mode. It still omits whether the session persists, how it terminates, or whether repeated calls are idempotent, but the non-persistence and billing disclosure are meaningful additions.

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

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

Three short sentences, front-loaded with the defining characteristic of the state, and no filler. It is tightly sized, though the parenthetical "(payment_mode)" is slightly redundant against the 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?

There is no output schema, and the description does not say what a successful call returns (e.g., a session identifier) or how the session ends. For a session-creation tool among several session siblings, that lifecycle gap leaves the definition only minimally 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 only two parameters, so the schema already documents auth_token and payment_mode thoroughly. The description only restates the payment_mode enum values (free/earned-only/external) without adding format or consequence details 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 conveys the effect ("enter a non-productive state") but never names the resource it acts on — the ISE session is only identified in the title and sibling names like exit_ise_session/get_ise_status. It does not explicitly distinguish itself from the sibling create_sdac_session, so an agent must infer that ISE is the non-accountable counterpart. Purpose is understandable but not crisply stated as a verb+resource.

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

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

The condition "where no decision, execution, or accountability declaration is required" implicitly tells an agent when this state is appropriate, which is more than nothing. However, it names no alternative (create_sdac_session) and gives no guidance on the session lifecycle or when to use exit_ise_session instead of simply not creating one. Usage is inferable rather than explicit.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-but-safe profile is covered. The description adds the useful context that it is a simulation and low-cost, but says nothing about session lifetime, follow-up tools (get_sdac_session/end_sdac_session), or what comes back.

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 tight sentences, purpose front-loaded, and the rationale sentence earns its place by conveying cost/risk context. 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?

For a one-optional-parameter session creator with no output schema, the description conveys enough to call it correctly and understand why. It is slightly incomplete on session lifecycle and its relationship to the sibling session-creation and session-retrieval tools.

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

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

There is a single optional auth_token whose schema description is fully documented (100% coverage). The description adds no parameter detail, so the baseline of 3 applies since the schema carries the load.

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?

States a specific verb ('Start') and resource ('simulation session'), and the second sentence clarifies intent ('Test EE combinations'). However, it never distinguishes this session from the sibling create_ise_session, which also creates a session, so the agent must guess which creator to 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?

The phrase 'before creating real decisions' implies sequencing relative to create_decision and gives a soft reason to prefer this tool for experimentation. It stops short of naming an alternative or stating when NOT to start a simulation session.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the write/destroy nature is covered. The description adds genuinely new behavioral context: cost is settled at close time, and the session stays 'open' (blocking create_sdac_session) until this runs. It does not cover what the settlement response looks like, but that is a small gap given the 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 short sentences, each carrying new information: the action, the trigger, and the sibling-tool consequence. Front-loaded and waste-free.

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

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

For a session-close mutation with no output schema, the description covers action, side effect (cost settlement) and the downstream 409 effect, while annotations carry safety. Only the return/settlement result format is unaddressed, which is a minor omission.

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 itself documents auth_token precedence and the two-step x402 payment_signature flow in detail. The description adds no parameter-level 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?

States a specific verb+resource ('End a simulation session') and adds the consequential outcome ('settle its accumulated cost'). It also implicitly distinguishes itself from get_sdac_session and the create_* siblings by naming create_sdac_session and its 409 SESSION_EXISTS behavior.

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?

Gives an explicit trigger ('Call this when you are done') and a concrete dependency: create_sdac_session returns 409 until the session is closed. It stops short of naming an alternative tool (e.g. get_sdac_session for status-only reads), so it is clear context without full when-not coverage.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the session-locking side effect (create_ise_session returns 409 until closed) and the settling/terminal nature of the call, though it never explains what 'settle' entails financially or state-wise.

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

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

Three short sentences, zero filler, with the core action front-loaded and the operational consequence placed last where it is most useful.

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 no-required-param, no-output-schema teardown tool, the description covers purpose, timing, and the cross-tool side effect. Missing only minor details like idempotency on repeated calls or whether settlement has irreversible effects, which would matter for a destructiveHint=true 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% and both parameters (auth_token, payment_signature) are fully documented in the schema, including the x402 challenge flow. The description adds nothing about parameters, 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?

States a clear verb+resource ('End your active ISE session and settle it'), which is unambiguous about the operation. It does not explicitly contrast with the sibling end_sdac_session, so differentiation relies on the agent recognizing the ISE vs SDAC naming.

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?

'Call this when you are done' gives direct timing guidance, and the 409 SESSION_EXISTS consequence of create_ise_session explains why the session must be closed before starting another. No explicit when-not or alternative-tool routing is provided, 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?

The description adds genuinely useful behavioral context absent from the annotations: x402 payment is required for observing another agent, the Trial does not cover ARA observation, and self-observation is free. However, it frames the call as 'View' while the annotations declare destructiveHint=true and readOnlyHint=false, and it never explains that destructive side. The gap between the read-like framing and the destructive flag is left unexplained.

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 what the tool returns, then the cost rules. No filler. Slightly dense in the second sentence but every clause carries 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?

With no output schema, the description usefully sketches the return content (trajectory shape, EE patterns, activity summary) and covers the payment prerequisite. Completeness is only undercut by the unexplained destructive annotation, which the description should have reconciled.

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 itself already documents agent_id and the full two-call x402 payment flow for payment_signature. The description adds no parameter-level detail (e.g., what an 'agent_id' is or how to obtain it), 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?

States a specific verb and resource ('View an agent's decision profile') and enumerates what the profile contains: trajectory shape, EE patterns, activity summary. It is clearly distinguishable from siblings like observe_pattern or get_evidence_report, though it never names an alternative to contrast against.

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 cost/eligibility context (paid for another agent, free for your own agent_id), which implies when you can call it, but it never states when to prefer this over sibling observation tools (observe_pattern, get_self_classification_distribution) or any prerequisite ordering. Usage is implied rather than instructed.

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, so the safety profile is covered. The description adds genuinely useful boundary context the annotations cannot: external payments are settled per call via x402 and are deliberately not reflected as a balance. It stops short of describing refresh timing or caching.

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 what is reported and closing with the one exclusion an agent might otherwise misread. 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?

With no output schema, the description carries the return-value burden and does list the reported fields (Earned DAC, Trial DAC, days left). For a zero-required-param read tool this is close to complete; only the exact response shape remains unspecified.

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?

There is a single optional auth_token with 100% schema description coverage, including header/env fallback and precedence rules. The description adds nothing about parameters, which is acceptable given the schema fully documents them, but it also does not reinforce the optionality.

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 names a specific verb (Check) and resource (DAC balances) and enumerates what it reports: Earned DAC balance plus Trial status with remaining Trial DAC and days left. It does not explicitly distinguish itself from the sibling get_trial_status, which is the one nearby tool an agent could confuse it with.

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

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

Usage is only implied - an agent infers it should call this when it needs to know its balance. There is no explicit when-to-use guidance, no prerequisites, and no routing away from alternatives such as get_trial_status or get_dac_ur.

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 safety profile is covered. The description adds that the report is a spending breakdown across three dimensions, which is useful context, but says nothing about date-range defaults, pagination, or response shape for a report 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?

Two tight sentences, no waste, with the core purpose front-loaded before the usage hint. Minor gap: it could be compressed further or structured as purpose-then-when.

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

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

For a read-only report tool with full schema coverage and no output schema, the description is nearly sufficient: it names the tool's function and the report's breakdown dimensions. The main residual gap is that it doesn't describe the returned report structure, which matters somewhat given no output schema exists.

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

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

Schema description coverage is 100%, so all three parameters (from, to, auth_token) are already documented in the schema, including the auth fallback precedence. The description adds the aggregation dimensions (service, period, transaction type) but no syntax or format guidance beyond the schema. 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?

States a specific verb and resource (view DAC usage report) plus the report's content dimensions: spending by service, period, and transaction type. This distinguishes it from the sibling get_dac_balance (point-in-time balance vs. historical breakdown), though it never names that sibling explicitly.

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

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

'Useful for budgeting and trajectory analysis' implies the use case but gives no explicit when-to-use or when-not-to-use guidance and never routes the agent between this and get_dac_balance or the various session/anomaly siblings.

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

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

Adds meaningful context beyond the annotations by disclosing the return's nature: 'the decision's formal shape (enums, timestamps, hash), never its content.' This tells the agent it will not get the actual decision payload, which is valuable since there is no output schema. Note the readOnlyHint=false annotation is not reconciled with the read-only framing of 'Retrieve'.

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 tight sentences, fully front-loaded: the retrieval action and returned shape lead, the lineage note trails. Every clause carries information and nothing is redundant.

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

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

With no output schema, the description usefully compensates by describing the returned 'formal shape (enums, timestamps, hash)' and explicitly stating it excludes content. Combined with the fully documented auth parameter, an agent has what it needs, though the readOnlyHint=false signal remains unexplained.

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 both parameters (dd_id, auth_token) are already documented in the schema, including the auth precedence rule. The description only restates 'by its ID' and adds no syntax or format detail beyond the schema 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?

States a specific verb (Retrieve) and resource (a specific decision record) and scopes what is returned: 'what was declared, when, and at what scope, plus its place in the lineage.' An agent can distinguish it from list_decisions and get_decision_metadata_distribution by the singular, ID-based retrieval, though no sibling is named explicitly.

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

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

Usage is implied by 'by its ID' — you need a DD ID to call it — but there is no explicit when-to-use versus list_decisions or when-not guidance, and no stated preconditions beyond the required dd_id the schema already enforces.

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 safety profile is covered. The description adds genuinely useful behavioral context beyond that: it is currently free to call, and if pricing is enabled it returns 402 with payment terms instead. This discloses the pricing/payment flow that the agent would otherwise be surprised by.

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

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

Two sentences with the core purpose front-loaded and no wasted text; the payment caveat is a relevant second sentence. Slightly long but each clause earns its place.

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

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

No output schema exists, so the description usefully enumerates the breakdown dimensions the agent will receive. Combined with the annotations and 100%-covered schema, an agent has enough to call it correctly, though the return shape (counts vs. proportions) is not specified.

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 both auth_token and payment_signature fully documented in the schema, including precedence and the challenge-then-sign flow. The description adds no parameter meaning beyond that, 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 names a specific verb ('observe') and resource ('your decision metadata distribution') and enumerates the exact dimensions returned (decision_class, target_class, decision_trigger, human_involvement) scoped to 'branch-1 decisions'. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling 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?

It implies context by scoping the output to 'your branch-1 decisions' and explains the free-vs-paid calling situation, but it never states when to use this tool over alternatives such as get_self_classification_distribution. Usage must be inferred.

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 safety is covered. The description usefully discloses the scope of content returned, but says nothing about size, format, or whether the guide is static or agent-specific — modest added value over 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?

Two sentences, purpose front-loaded, with the topic enumeration acting as a useful retrieval index. The acronym list (ARA, TSL, ISE, sDAC, ASA, DUR) is dense but serves the matching purpose rather than padding.

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 no-parameter, read-only, no-output-schema documentation fetch, the definition tells an agent exactly what it will get and when to reach for it. Only the absence of any hint about guide length or freshness keeps it from being fully complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the schema is trivially complete at 100% 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?

States a specific verb and resource — 'Retrieve the full agent guide for Decision Anchor' — and enumerates the topical coverage it returns (cost structure, ARA layers, TSL, ISE, sDAC, etc.). No sibling tool competes with it, though the description doesn't explicitly say so.

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?

'Use when you need background on any of these topics' gives a trigger condition, but it is essentially circular — use the docs tool when you need docs. No alternatives, no when-not guidance, and no indication of when this beats querying structured tools like get_dac_balance or get_ise_status.

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

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

Annotations only declare readOnlyHint=false / destructiveHint=true without saying what is affected; the description supplies the missing context: a DAC cost is incurred, and a k-anonymity threshold (returned as metadata.k_anonymity_threshold) suppresses comparisons on low-participation days. That explains the de-identification behavior and the spend side effect that plausibly justifies the non-read-only annotation. It still does not say what, if anything, is destroyed or whether the cost is charged on a failed call, so it stops short of a 5.

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

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

Three sentences, front-loaded with the resource and payload, then the privacy rule, then cost. Every sentence carries content, though the k-anonymity sentence is dense and could be tightened.

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

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

No output schema exists, so the description must cover returns, and it does name the payload (within_band/outlier counts per dimension) plus the returned metadata key. Together with annotations and a fully covered schema, an agent has enough to call this correctly; only the sibling-relative placement is missing.

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

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

Schema description coverage is 100%, so the schema already documents dimension, auth_token, period_days, and the payment_signature two-step flow; the baseline is 3. The description reinforces the payment pattern and reveals the k-anonymity metadata, but adds no field-level syntax or enum semantics (e.g., what each dimension value means) 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?

States a specific verb (observe) and resource (environment-level anomaly distribution) and names the exact payload shape: within_band/outlier counts per dimension across the population. That is far more specific than the title alone. However, it never names or contrasts itself with near siblings like compare_anomaly, get_decision_metadata_distribution, or observe_environment, leaving the agent to infer which distribution tool to pick.

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

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

There is invocation mechanics guidance (omit payment_signature on the first call to get the challenge, then re-call with identical args), but no statement of when this tool is appropriate versus its siblings or what conditions exclude it. For a tool sitting among several *_distribution and observe_* siblings, the absence of routing guidance is a real gap.

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 declare readOnlyHint=false and destructiveHint=true, which is counterintuitive for a 'get_' tool, and the description never explains what is destructive or why. It does add one genuinely useful behavioral fact beyond the annotations: the call costs DAC, which matters for invocation. The core oddity (a getter flagged destructive) goes unaddressed, so the disclosure is partial.

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?

Four short clauses, no filler, and the key fact (what the report is, who it is for) is front-loaded. The middle sentence is a comma-spliced list of report contents rather than clean prose, which slightly hurts readability but not economy.

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

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

With no output schema, the description carries the burden of describing the return value and does so by naming the report's sections. The payment path is fully covered by the input schema. Remaining gaps are the report's actual format/serialization and the meaning of 'EE resolution', which an external-audit consumer would want.

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 descriptions for auth_token and payment_signature are detailed, including the full x402 first-call/second-call flow. The description contributes only the 'Costs DAC' fact that motivates payment_signature. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names a specific verb and resource (an external-audience evidence report for one of your decisions) and enumerates its contents (decision metadata, EE resolution, responsibility declaration). That is far more concrete than the bare name. It does not, however, contrast itself against near siblings like get_decision or get_decision_metadata_distribution, so an agent must infer the distinction from the 'external audit' framing.

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?

Usage context is implied rather than stated: 'external-audience' and 'structured for external audit review' signal this is for external audit scenarios, and 'Costs DAC' warns of a paid call. No alternative tool is named and no when-not condition is given, so routing versus get_decision is left to 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds context annotations cannot carry, namely that the call is free and that its result previews what exit_ise_session will terminate. It does not discuss return format, which is what keeps it from a 5.

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

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

Three short sentences, zero filler, with the purpose front-loaded before the cost and the cross-tool hint. Every sentence earns its place.

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

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

No output schema exists, yet the description names the three things the agent gets back (session existence, elapsed time, billing mode), which is sufficient for a trivial read-only status check with one optional auth parameter.

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?

There is a single, fully documented auth_token with 100% schema description coverage, so the schema already carries the parameter semantics. The description adds nothing about the parameter, making the baseline 3 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?

States a specific verb and resource ('Check whether you have an active ISE session') plus the exact fields returned ('elapsed time and billing mode'), and explicitly ties itself to the sibling exit_ise_session rather than leaving that relation implicit.

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?

Gives clear context for use ('Use this to find out what exit_ise_session will close') and names the cost ('Free'), so the agent knows the scenario. It stops short of an explicit when-not / alternative routing statement, so 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 cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds a genuinely non-derivable behavioral trait: the lookup is 'Free.' That billing/cost transparency is exactly the kind of context structured fields cannot convey. It stops short of describing error behavior for a missing session, so not a 5.

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

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

Three short clauses, zero padding, and the core action and returned fields are front-loaded before the cost note and workflow hint. 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?

With no output schema, the description compensates by naming the returned fields (status, trial count, accumulated cost), and the input schema is fully documented. A brief note on behavior for an invalid/unknown session ID is the only missing piece for a lookup tool of this 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 coverage is 100%, so both session_id (including its origin from create_sdac_session) and the optional auth_token are fully documented in the schema. The description adds no format, syntax, or fallback detail beyond that, matching the baseline 3.

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

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

States a specific verb ('look up') and resource ('simulation session by ID') and enumerates what it returns: status, trial count, accumulated cost. It is clearly distinguishable from create_sdac_session and end_sdac_session, and it names the latter as the downstream consumer.

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?

Gives an explicit context for use: 'Use this to see what end_sdac_session will settle,' which ties the tool to a concrete workflow moment and names a sibling. It does not say when *not* to use it, but for a simple read that is a minor gap.

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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the scoping detail that the distribution spans the agent's own branch-1 decisions; it says nothing about the shape, granularity, or freshness of the returned distribution, which would be the useful added 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?

A single short sentence with zero filler, and the object of the operation is front-loaded. Nothing can be trimmed without losing 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?

There is no output schema, so the description should give the agent some sense of what a 'distribution' return looks like and what 'branch-1 decisions' scope means, and it does not. For a read-only tool with one optional parameter this is adequate but leaves a real gap around return expectations.

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

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

The only parameter (auth_token) is fully described in the schema, including its optionality and precedence rules, so the schema already does all the work. The description contributes no parameter meaning beyond that, which is the expected baseline for 100% 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?

States a specific verb ('Observe') and resource ('your self_classification distribution') with an explicit scope of 'branch-1 decisions.' However, it does not distinguish itself from the similarly shaped sibling get_decision_metadata_distribution, and the terms 'self_classification' and 'branch-1 decisions' are domain jargon an agent cannot resolve from the description alone.

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

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

There is no when-to-use guidance, no statement of prerequisites, and no mention of alternatives such as get_decision_metadata_distribution or list_classifications. The agent is left to infer that this is a read/reporting call from annotations alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered, and the description goes further by disclosing the semantics of the payload: remaining plus used equals the granted amount, and the balance is scoped to specific routes. That arithmetic relationship is genuine context an agent cannot get from annotations or schema. It stops short of describing pagination, error behavior, or freshness of the values.

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 purpose is front-loaded in the first sentence and the response enumeration follows as a single readable clause list with no filler. The list of returned fields is long but each item earns its place given no output schema exists.

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

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

With no output schema, the description carries the burden of describing the return shape and does so thoroughly, including the derived relationship between remaining and used DAC. It would be a 5 if it clarified the trial-vs-general balance distinction relative to get_dac_balance, but as a self-contained status read it 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?

There is a single optional parameter (auth_token) and schema description coverage is 100%, so the schema already explains the header-vs-explicit precedence rule in full. The description adds nothing about the parameter, which is the expected baseline when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: check the caller's trial account status, and it enumerates the exact fields the answer carries (active flag, remaining DAC, used DAC, expiry, routes). It never distinguishes itself from the closely related sibling get_dac_balance, so an agent with both in its toolset must guess which one answers a balance question.

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?

Usage is only implied by "Check your trial account status" — the agent can infer this is a self-scoped status read, but there is no explicit when-to-use statement, no prerequisites, and no mention of when to prefer this over get_dac_balance or get_ise_status.

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 safety profile is covered. The description adds the useful context that results are a superset of operator base plus owner-registered categories, but says nothing about auth requirements, ordering, or pagination beyond that.

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 tight sentences with zero waste: the first defines the resource and its scope, the second routes the output to its consumer. Front-loaded and appropriately sized for a trivial list 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?

With no output schema, the description conveys what the returned keys represent and how to use them downstream, which is the key completeness gap for a list tool. Minor gap is the absence of any note on return ordering or count, but nothing an agent needs to invoke it correctly is missing.

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

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

Only one parameter (auth_token) exists and the schema documents it at 100% coverage, so the description carries no additional parameter burden. It correctly omits redundant param details, which is the expected baseline when the schema does the work.

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?

States a specific verb (List) and resource (self_classification categories) and clarifies the category sources as operator base plus owner-registered. Clear and distinguishable, though it doesn't explicitly name a sibling it replaces, which would be required for a 5.

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 the agent where the returned keys are consumed: create_decision template.self_classification when content_inclusion_flag=1. It names the sibling tool and the exact condition that selects it, leaving nothing to 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description's only behavioral hint is 'the trajectory built so far', which loosely suggests a chronological decision sequence, but it doesn't disclose ordering, pagination behavior, or result volume. Little added 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?

A single short sentence, front-loaded with the action and resource. It is efficient, though the second clause is vague filler rather than earning its place.

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

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

With no output schema, the description should ideally hint at the return shape (what a decision record contains) and pagination ordering, since limit/offset are present. The 'trajectory built so far' phrase gestures at this but does not make it concrete, leaving an adequate-but-thin definition.

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

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

Schema description coverage is 100%, so all five parameters (from, to, limit, offset, auth_token) are already documented, including auth fallback and pagination. The description adds nothing about parameter semantics, 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?

States a clear verb+resource ('List your decision records'), which is enough to identify the operation. However, the trailing clause 'the trajectory built so far' is vague and adds no distinguishing detail, and no sibling (e.g. get_decision, get_decision_metadata_distribution) is referenced to clarify scope.

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

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

No when-to-use guidance, prerequisites, or alternatives are given. Nothing tells the agent why to call this rather than get_decision or get_decision_metadata_distribution, both of which appear in the sibling list.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered externally. The description adds no behavioral context beyond that: nothing about pagination, default page size, result ordering, or whether the listing reflects live marketplace state.

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

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

Two short, front-loaded sentences with no filler; the verb and resource lead. It is efficient, though arguably thin given the untapped room for paging 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?

With no output schema and four optional parameters, the description should say at least roughly what a listing entry contains or how results are paged, and it does not. Safety and filtering are otherwise adequately covered by annotations and schema, making this 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?

Schema description coverage is 100% with two enum-typed filters, so the schema already carries the parameter semantics. The description adds nothing about what 'layer' means or how paging interacts with limit, 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 states a clear verb+resource pair: browsing a tool marketplace where agents publish tools. It is distinguishable from mutation siblings like register_tool and purchase_tool, but it does not explicitly contrast itself with the other list_* tools (list_decisions, list_classifications).

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

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

There is no when-to-use guidance, no mention of alternatives, and nothing about how browsing relates to register_tool/purchase_tool in a typical discover-then-acquire flow. The purpose is implied but the agent gets no routing conditions.

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

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

Annotations mark this non-read-only and destructive, and the description corroborates that by disclosing the paid nature of the call: cost comes from ARA observation pricing, payment via x402, Trial does not cover ARA observation, and the charge is returned as dac_charged. This adds real behavioral context beyond the safety hints, though it does not explain the two-step challenge/sign cycle's failure modes.

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?

Front-loads what is observed, then moves to prerequisites, cost, and the single return value. Four compact sentences with no filler, though the payment sentence is dense enough to require a second read.

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 paid tool with no output schema, the definition covers auth, pricing source, payment protocol, trial exclusion, and the returned dac_charged field, which is close to complete. Missing only the multi-call payment flow already hinted at in the 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 description coverage is 100%, so both parameters are already documented in detail, giving a baseline of 3. The description's only parameter claim is that auth_token is 'Required', which slightly conflicts with the schema's statement that it is optional when a bearer header or DA_AUTH_TOKEN is present.

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?

States a specific verb (observe) and resource (aggregate environment statistics), then enumerates what is observed: active agents, total decisions, activity density. This distinguishes it from siblings like observe_pattern and get_environment_anomaly, though it never names those alternatives explicitly.

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

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

No explicit when-to-use versus-when-to-use-alternative guidance is given. It does supply a useful procedural rule (omit payment_signature on the first call to receive the challenge), which is genuine invocation guidance, but the reader must infer when this tool beats observing patterns or anomalies.

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=false and destructiveHint=true, so the safety profile is covered by structured data. The description adds meaningful context beyond that: it requires auth_token, is billed at current ARA observation pricing via x402, is excluded from Trial coverage, and returns the charge as dac_charged. It still doesn't explain why an 'observe' call is flagged destructive, but the added payment/auth behavior is substantive.

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

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

Three sentences, front-loaded with what the tool observes, then auth, then billing. Every sentence carries information; only minor phrasing ('The cost comes from...') is slightly loose.

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 paid, auth-gated observation tool with no output schema, the description covers the essentials an agent needs: auth requirement, payment flow, trial exclusion, and the returned charge field. The main remaining gap is the unexplained destructive annotation and the lack of sibling routing guidance.

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 auth_token, payment_signature, and type are already fully documented in the schema, making 3 the baseline. The description reinforces the auth requirement and names the dac_charged return field but adds no syntax or format detail beyond the schema.

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

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

The description states a specific verb and resource: 'Observe pattern-level EE distributions and action-type breakdowns across agents,' which is concrete and matches the 'type' enum. It does not, however, differentiate itself from distribution-oriented siblings such as get_self_classification_distribution or observe_environment, so an agent isn't told which observation tool to reach for.

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 real preconditions – auth_token required, paid via x402, and Trial does not cover ARA observation – which is more than nothing. But it never states when to prefer this tool over the many sibling observation/distribution tools, so usage selection is left 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 declare readOnlyHint=false and destructiveHint=true. The description usefully adds that the call creates a pending DD and 'waits for counterparty acceptance', which tempers the destructive flag. But it never explains the destructive aspect, the auth/idempotency implications, or the two-call x402 payment challenge flow that the schema implies.

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

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

Three sentences, front-loaded with the usage condition, then scenarios, then mechanics. No filler, though the jargon density ('fix a shared boundary', 'anchored') slightly reduces immediate comprehension.

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 mutation tool with no output schema and an unexplained destructiveHint, the description covers the conceptual 'why' but not operational essentials: the payment challenge round-trip, retention/access implications, or what the agent receives back while awaiting acceptance.

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% across 21 parameters, so the schema carries full parameter meaning. The description adds no parameter-level guidance (e.g., how decision_action_type or delegation_state interact with the bilateral flow). 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?

States a specific verb (propose) and resource (bilateral agreement / DD with declaration_mode 'bilateral'), and the outcome differs clearly from siblings like create_decision and confirm_decision. However, the description leans on undefined internal jargon ('DD', 'boundary anchored'), so an agent gets the gist but not a crisp object model.

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 opening clause gives a genuine precondition: 'two agents need to fix a shared boundary' where 'both sides must agree before the boundary is anchored.' It also names example scenarios (payment splits, task delegation). It stops short of naming alternatives or stating when not to use it versus create_decision/confirm_decision.

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 declare destructiveHint=true and readOnlyHint=false, and the description corroborates this is a spend/purchase operation where the creator earns DAC. It adds substantive context beyond annotations: the payment mechanism (x402), the two-call challenge/sign flow, and the explicit trust boundary that Decision Anchor never holds the key or signs on the user's behalf.

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 tightly scoped sentences: purpose, economic effect, and payment mechanism/limitation. No filler; every clause carries information an agent needs to decide whether and how to call it.

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 purpose, payment flow constraint, and trust boundary. No output schema exists, so return values aren't described, though the description does hint at the challenge response on the first call. Slightly more on the two-step invocation could help, but it's largely complete for a purchase tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the paid-call flow (first call returns the challenge, second call submits the signature) and confirming the trial route can't substitute, which enriches understanding of payment_signature beyond the schema text.

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

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

States a specific verb (Purchase) and resource (a tool from the marketplace), immediately distinguishing it from siblings like list_tools, register_tool, and run_sdac_trial. An agent can tell exactly what this tool does.

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 notes the trial route doesn't cover this path and mentions x402 payment, implying this is the paid acquisition path vs. run_sdac_trial. However, it never explicitly says 'use this instead of X' or names the alternative route by name, leaving some inference required.

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 declare readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is already covered. The description adds genuinely new context — that subsequent decisions accumulate into an externally observable trajectory — but omits whether registration is idempotent, what it returns, or what happens on re-registration.

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 with the effect front-loaded ahead of the observational consequence. Tight and readable, though the second sentence drifts slightly from the core purpose of explaining what registration does.

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-required-param tool with a single fully-documented optional parameter and no output schema, the definition is minimally adequate. It still leaves the agent unsure of what registration produces, whether it must precede other calls, and how it differs from register_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% and region_code has an exceptionally thorough schema description (enum values, fallback behavior, override semantics, metadata-only note). The description adds nothing beyond the schema, 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 verb 'Register' is present, but the resource is vague ('in this environment') and the agent it registers is left implicit. It does not differentiate itself from the sibling register_tool, so an agent cannot tell which registration path to take from the description alone.

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 when-to-use, when-not-to-use, or prerequisite guidance is given. The second sentence gestures at a consequence (decisions become an observable trajectory) but never tells the agent when registration is required or how it relates to siblings like register_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 declare readOnlyHint=false and destructiveHint=false, so the mutation profile is partly covered. The description adds the revenue/pricing behavior, which is useful context, but omits prerequisites such as the auth token requirement and the fact that registration is rejected with 400 INVALID_ARA_CONNECTION for invalid connections (that detail lives only in 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?

Two compact sentences with the core action front-loaded and the incentive second. No filler, no redundancy with the title.

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 mutation tool with no output schema and a fully documented input schema, the description is adequate but thin: it never mentions auth requirements, validation failure modes, or what a successful registration returns. The structured fields carry most of the load, leaving the description minimally viable.

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 tool_name, price_dac, ara_connections and the layer enum. The description only reinforces the DAC pricing notion and adds nothing about the layered/ARA connection syntax beyond what the schema provides. 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?

States a specific verb and resource: 'Publish a tool you built to the marketplace.' This clearly distinguishes it from siblings like purchase_tool and list_tools, and the secondary sentence clarifies the monetization outcome. It stops short of naming sibling alternatives explicitly, but the action 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?

The description says what happens (price in DAC, earn revenue) but gives no when-to-use guidance, no prerequisites, and no mention of the alternative purchase_tool. An agent gets no help deciding under what circumstances registration is appropriate versus other marketplace actions.

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

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

Annotations only give readOnlyHint=false/destructiveHint=false; the description adds substantive context beyond them: no real record is created, the call is free upfront, and each trial accrues cost that end_sdac_session settles (trial_count x sdac_cost_ratio x base fee). This deferred-cost behavior is exactly the kind of trait an agent cannot infer from annotations. It omits return/pagination detail, keeping it at 4.

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 tight sentences, front-loaded with the core action and the no-persist guarantee, then the return value, then the cost model. Each sentence carries distinct information; slightly dense but 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?

With no output schema, the description correctly explains the return value (the DAC the combination would cost on create_decision). It also ties the tool into the session lifecycle via end_sdac_session. Complete enough to call safely, though it does not describe the session-state requirements in more detail.

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 enums documented for all optional parameters, so the schema carries the parameter burden. The description adds the concept of an 'EE combination' and links outputs to DAC, but does not clarify any individual parameter beyond the schema. 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?

States a specific verb+resource ('Price an EE combination inside a simulation session') and immediately contrasts it with the sibling create_decision ('without creating a real record'). An agent can distinguish this from create_decision without opening either schema.

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 frames the use context: dry-run pricing inside an active sDAC session vs. actually calling create_decision. It does not include an explicit 'when-not-to-use' exclusion, but the alternative is named implicitly and the session/end_sdac_session coupling gives strong situational 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 disclose readOnlyHint=false and destructiveHint=false, so the write-but-safe profile is already known. The description adds that every field is optional and that nothing downstream depends on the call, which is meaningful 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?

Three short sentences, front-loaded with purpose, then usage, then the non-dependency caveat. No padding, though the first sentence is slightly verbose in restating 'what worked and what did not'.

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

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

With no output schema, the description should carry behavioral weight, and it covers optionality, non-destructiveness, and the absence of downstream dependencies. Nothing critical for correct invocation appears to be missing for a simple feedback submission tool.

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

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

Schema coverage is 100% with all 8 parameters individually described, so the baseline is 3. The description only reinforces optionality ('Every field is optional'), which the schema already shows via zero required parameters, adding no new semantic 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?

States a specific verb (records) and resource (feedback note about the environment) and scopes it to 'what worked and what did not'. It is clearly distinguishable from siblings, none of which collect feedback, though 'short note' understates an 8-field submission.

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 it ('when you or the user want to leave feedback') and clarifies that no other tool depends on it, removing any concern about ordering. No alternatives are named, but no sibling offers comparable functionality, so none are needed.

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