AgentWork Outcome Router

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

With no annotations, the description carries full responsibility. 'Inspect' implies a read-only operation, but it does not explicitly state side effects, auth requirements, or whether it only returns status. The 'disabled-by-default' trait refers to the policy, not the tool's behavior.

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

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

A single, well-structured sentence that communicates the tool's function with no wasted words. It is appropriately front-loaded.

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

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

While the tool is simple with no parameters, the description omits any indication of what the output will look like or how the result is structured. Given the lack of an output schema, this information would be valuable for a complete understanding.

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

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

The tool has zero parameters, so the schema provides full coverage by default. The baseline of 4 applies, and the description does not need to add parameter details.

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

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

The description uses a specific verb 'Inspect' and clearly identifies the resources: AgentWork's purchasing policy and Cloudflare Wallet adapter status. This distinguishes it well from siblings focused on blocked outcomes and search operations.

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

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

No guidance is provided on when to use this tool versus alternatives, and there are no exclusions or context clues. The agent must infer usage solely from the tool's purpose.

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

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

With no annotations provided, the description carries the full burden. It discloses that refresh reruns discovery without creating or rate-counting a second request, that refresh is cooldown- and attempt-limited, that the tool cannot confirm for an owner, and that the token must not be placed in a URL. These are meaningful behavioral traits beyond the basic read operation. It does not explicitly state idempotency or the response format, but the read nature is clear. This is strong disclosure for a tool with zero 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?

The description is multi-sentence but front-loads the core purpose in the first clause. Every sentence adds functional information: parameter conditions, rate limits, a limitation, and a security warning. There is no fluff or repetition. It is slightly dense but appropriately scoped for the complexity of the tool. It earns its length.

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

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

Given there is no output schema, the description could have described the return format, but for a read tool that primarily reports lifecycle state, that is not critical. It covers the key execution aspects: input requirements, refresh conditions, rate limits, ownership confirmation limitation, and token handling. It does not mention prerequisites like authentication, but the sibling tools context suggests this is a safe read operation. Overall, it is sufficiently complete for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the semantics of refresh (when to set true, side effects such as rerunning discovery without creating a new request) and clarifies that the request_token is the token argument (not a URL). It does not explicitly describe request_id, but its role as a UUID for the request is self-evident from the name and context. The description adds meaning to two of three parameters, significantly compensating for the schema's lack of descriptions.

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

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

The description clearly states the tool reads a specific resource: the 'private persisted route or owner-confirmed escalation lifecycle' for a given AgentWork request ID. The verb 'Read' unambiguously indicates a non-mutating operation, and the mention 'cannot confirm for an owner' distinguishes it from sibling action tools like resolve_blocker or report_blocker_outcome. It is specific enough that an agent can differentiate it without opening the 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?

The description provides explicit conditions for using the refresh parameter ('only when an unselected route remains unresolved and current executable supply may have changed') and warns of cooldown/attempt limits. It also gives a security directive for the request token ('never a URL'). However, it stops short of explicitly contrasting this tool with each sibling, though it implies it is for reading only and cannot confirm for an owner. This is clear usage guidance with a minor gap in naming alternatives.

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

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

With no annotations, the description carries the full burden. It mentions 'current verified' and a 'reusable 24-hour AgentWork pass', but does not clarify what verification means, how the pass works, or what happens if the pass is invalid or the opportunity is not found. The behavior is only minimally disclosed and the pass reference is vague.

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

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

The description is a single short sentence, front-loaded with the core action. It is concise, but the phrase 'using the same reusable 24-hour AgentWork pass' is somewhat unclear and could be considered extraneous. Overall, it is efficient but not perfectly structured.

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

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

The tool has no annotations and no output schema, so the description must cover return values and error behavior. It does not mention what the response object looks like, any potential errors, or prerequisites beyond the vague pass reference. The description is too sparse for a tool that must fully inform the agent on its own.

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 0%, so the description must compensate. However, it does not explain what the 'id' parameter represents or how to obtain it. The description only says 'Get one... opportunity', implying the id is an opportunity identifier, but it never explicitly says 'by ID' or provides any context for the parameter. This is insufficient given the lack of schema descriptions.

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

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

The description clearly states the tool's function: to retrieve a single, current, verified opportunity. The verb 'Get' plus the resource 'opportunity' is specific, and the 'one' distinguishes it from list/search tools. It doesn't explicitly contrast with sibling tools, but the purpose is clear enough.

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

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

No guidance is provided about when to use this tool versus alternatives like search_work or search_services. There is no mention of having an opportunity ID, when to prefer this over a search, or any exclusions. The description lacks any usage context.

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

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

With no annotations provided, the description carries the full burden. It discloses that the execution status is private, gives a security-critical instruction about token placement, and defines a polling termination condition. This adds meaningful behavioral context, though error handling and return details are not covered.

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

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

The description is two sentences long, front-loaded with the core purpose and then providing essential usage instructions. Every word earns its place, with no redundancy or filler.

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

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

For a simple polling read tool, the description covers key usage aspects including privacy, token handling, and when to stop polling. However, without an output schema, it does not explain what the response will contain beyond 'completion evidence', leaving some ambiguity for an agent.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It only explains the token parameter ('put the token in this tool argument') and leaves request_id's meaning implicit. This is insufficient for an agent to understand how to obtain or use the request_id.

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

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

The description clearly identifies the tool as reading private execution status and completion evidence, using a specific verb ('read') and resource. It distinguishes this from sibling getters like get_blocker_resolution and get_opportunity by focusing on execution outcomes.

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

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

Provides clear usage context by instructing the agent to pass the token as an argument, never in a URL, and to poll only while the status is 'received or accepted'. It does not explicitly name alternatives, but the complementary relationship with request_outcome_execution is 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?

With no annotations provided, the description carries the full burden. It discloses that a route_failed report preserves the failed attempt and reopens the request, and that requester evidence is tracked but not independently verified. However, it does not describe the effects of other outcomes (attempted, acceptance_advanced, acceptance_passed) or whether the report is final, leaving gaps in transparency.

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

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

The description is brief and front-loaded with the main purpose, then adds one key clarifying detail about route_failed. There is no redundant wording; 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?

For a tool with 4 required parameters, no annotations, and no output schema, the description gives some context but lacks parameter explanations and full behavioral details for all outcomes. It is adequate for basic use but not fully complete for an agent to invoke without additional inference.

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

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

The schema has 0% description coverage, so the description should compensate. It only explains the route_failed outcome but does not clarify the meaning or format of request_id, request_token, evidence, or the semantics of the other enum values. This is a significant gap.

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

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

The description clearly states the tool's function: 'Report what happened after following the selected route.' It uses a specific verb ('Report') and resource, and distinguishes itself from sibling tools like request_outcome_execution by focusing on reporting the outcome. The special route_failed behavior also adds clarity.

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

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

The description implies the tool is used after following a selected route, which provides context for when to invoke it. It also explains the route_failed scenario and notes that evidence alone does not verify completion. However, it does not explicitly mention alternatives or when not to use this tool.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses asynchronous execution, permanent retention of validated privacy-safe asks, non-retention of rejected sensitive input, and the token requirement for status follow-up. It does not detail side effects or exact response shape, but the disclosed behavior is substantial.

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

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

The description is four sentences and each serves a purpose: primary action, async behavior, retention policy, and token guidance. It is front-loaded with the core purpose and contains no obvious filler, though it could be tightened without losing meaning.

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

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

For a complex async submission tool with no annotations and no output schema, it covers the essential operational context: submission, async execution, honest failure/evidence reporting, data retention, and token-based follow-up. It falls slightly short of explicitly naming the status-read sibling or describing the exact token-bearing response.

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

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

Schema description coverage is 80%, so the baseline is 3. The description adds almost no parameter-level meaning beyond the schema; terms like 'outcome' and 'ask' loosely relate to task and done_when but do not provide extra clarity on how to fill the parameters correctly.

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

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

The description names a concrete action: hand an outcome you cannot execute to AgentWork, and clarifies the asynchronous lifecycle with completion evidence or honest failure. It also explicitly separates itself from provider search, which helps an agent distinguish it from search-related siblings.

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

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

It states the trigger condition, use this when your agent cannot execute the outcome itself, and gives an explicit exclusion with 'This is not provider search.' It also implies a follow-up status read by telling the agent to save the private token, though it does not name the exact sibling tool for reading 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure, and it delivers. It states that the tool returns a private request ID and token before running discovery, that the token is returned only once, and that discovery cannot invoke, procure, pay, post, or expose private context. This gives the agent a strong safety and side-effect profile.

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

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

The description is three dense sentences with no filler. It front-loads the core purpose, then covers the immediate return value, the follow-up call, the one-time token warning, and the safety constraints. 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?

For a tool with seven parameters, nested objects, no annotations, and no output schema, the description covers the high-level workflow and safety model but leaves gaps around how to populate optional parameters like deadline, max_budget, and preference, and what the exact response contract is. It is clear enough for a simple submission but not fully complete for a complex tool.

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

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

The input schema has 57% description coverage, so some parameters are already documented, but the description adds almost no parameter-level meaning beyond implying that 'request' is the real task. It does not explain deadline, max_budget, preference, authority, context, or the complex escalation object, leaving the agent to infer their roles from the schema alone.

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

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

The description opens with a specific verb and resource: 'Submit one real task your agent cannot finish.' It clearly distinguishes this tool from get_blocker_resolution by explaining that resolve_blocker creates the request and returns credentials, while get_blocker_resolution consumes those credentials to run discovery. This leaves no ambiguity about what the tool is 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?

The description gives an explicit condition for use ('your agent cannot finish' a real task) and prescribes the next step: call get_blocker_resolution with the returned credentials. It does not explicitly list when not to use this tool or mention sibling alternatives like search_services or select_blocker_offer, but the workflow is clear enough that an agent can route itself correctly.

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

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

No annotations are provided, so the description carries the transparency burden. It only states what is searched and mentions evidence tiers, but does not disclose read-only behavior, authentication needs, rate limits, result format, or any side effects. This is a meaningful gap for a tool with no annotations.

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

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

The description is a single sentence, front-loaded with the tool's purpose, and contains no unnecessary words or repetition. It is appropriately concise.

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

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

The tool has 9 optional parameters, no output schema, and no annotations, creating a high complexity burden. The description only provides a high-level purpose and omits filtering mechanics, result structure, source semantics, and relationship to sibling tools, leaving the agent under-informed.

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 0% for 9 parameters, and the description does not explain any of them. It vaguely hints at service types and evidence tiers, but does not map those concepts to the 'source' or 'evidence' parameters, nor explain 'q', 'asset', 'limit', 'scheme', 'network', 'curated_only', or 'max_usd_price'. The minimal hint prevents a score of 1.

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

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

The description clearly states the tool searches for 'publisher-listed MCP services or x402-discovered paid services' with 'explicit evidence tiers,' giving a specific verb and resource scope. It distinguishes from general search but does not explicitly contrast with the sibling 'search_work' tool, so it falls short of 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?

There is no guidance on when to use this tool versus alternatives like 'search_work' or 'get_opportunity.' The description implies a search use case but provides no context, prerequisites, or exclusions.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does reveal a meaningful behavior: a x402 settlement grants a reusable 24-hour AgentWork pass, indicating a payment/access requirement. However, it does not disclose other behavioral traits such as result limits, ordering, or what happens without the pass.

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

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

The description is two sentences, front-loaded with the core purpose. The second sentence adds relevant access behavior without fluff. Every sentence earns its place, and it is appropriately concise for its length.

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

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

Despite having 11 parameters, no output schema, and no annotations, the description provides minimal context. It fails to explain filter semantics, return values, or usage nuances, leaving an agent under-informed for a complex search tool. The access pass note is helpful but insufficient to make the tool usable.

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 0%, and the description provides no explanation for any of the 11 parameters (q, sort, source, currency, etc.). The description focuses on the access pass but gives zero semantic context for how to use the filterable fields, making it impossible for an agent to correctly construct queries.

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

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

The description clearly states the tool searches for 'current verified paid work', which is a specific verb+resource combination. However, it does not explicitly distinguish from sibling tools like search_services, though the resource type (work vs. services) provides implicit differentiation.

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

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

The description implies the tool is used for searching paid work and adds a notable access precondition (x402 settlement grants a 24-hour pass), which gives some usage context. However, it does not provide explicit guidance on when to use this tool versus alternatives like search_services.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that selection does not 'silently charge or procure anything,' which is a key safety clarification. It also explains the behavioral difference between executing the offer directly vs deferring to AgentWork.

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

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

The description is three sentences long, with the primary purpose in the first sentence and no filler. Each sentence contributes distinct information: what the tool does, how the choice parameter works, and a crucial safety guarantee.

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 selection tool with no output schema, the description covers the core action, the two execution modes, and the non-charging safety behavior. It does not describe return values or post-selection effects in detail, but the essential decision-making context is present.

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 0%, so the description must compensate for all four parameters. It only explains the 'choice' parameter semantics. The identifiers 'request_id', 'request_token', and 'offer_id' are not qualified beyond the generic phrase 'on the original request,' leaving their roles and constraints under-specified.

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

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

The description clearly states the tool's verb ('Select') and resource ('one persisted blocker offer on the original request'), making its primary purpose unambiguous. It also distinguishes this tool from siblings by focusing on the act of choosing among offers rather than resolving or reporting the blocker.

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

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

The description provides clear guidance on the two choice values ('self_execute' vs 'agentwork_execute') and when each is appropriate. It does not explicitly mention alternatives among sibling tools, but the selection context is clear enough for typical usage.

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