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?

No annotations are provided, so the description carries full burden. It reveals that the operation is private and requires the token to be passed as an argument for security. However, it doesn't disclose potential side effects (though 'retrieve' suggests read-only), authorization requirements, or error behavior, leaving some ambiguity.

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

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

Two sentences, first clearly states purpose, second provides essential security guidance. No filler or redundancy; 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 two-parameter retrieval tool with no annotations and no output schema, the description gives the core purpose and a security note. It doesn't explain the request lifecycle or the response structure beyond 'status and evidence-backed route,' making it adequate but not rich.

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 mentions the token and its security handling but doesn't explain request_id's purpose or the meaning of the token beyond its format in the schema. Parameter names are self-explanatory, but the description adds little semantic value.

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

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

The description states a specific action ('retrieve the status and evidence-backed route') for a specific resource ('blocked-outcome request'), clearly distinguishing it from sibling tools like route_blocked_outcome which likely handle the routing action itself.

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

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

It provides a clear security guideline about token placement (in the tool argument, not a URL), which is important for correct usage. However, it doesn't explicitly contrast with alternatives or state when-not-to-use, but the context implies it's the private retrieval counterpart to route_blocked_outcome.

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, the description carries the behavioral burden. It does disclose a key trait: the report is self-reported product evidence, not payment or independently verified revenue. This adds meaningful context about the nature and trustworthiness of the operation. However, it does not disclose potential side effects, permission requirements, or failure behavior, leaving gaps.

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 primary purpose, and every word earns its place. The design is efficient and easy to parse, with no filler or repetition.

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

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

Given the absence of annotations, an output schema, and the 0% parameter coverage, the description is too sparse to fully contextualize the tool. It does not explain what 'delivered route' means, what evidence should look like, or the significance of request_id/token. While the caveat about self-report is useful, essential operational context 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 0%, so the description must compensate for parameter meanings. It partially does by listing the outcome values, which maps to the 'outcome' enum. However, it provides no explanation for 'evidence', 'request_id', or 'request_token', leaving these critical parameters undefined. The description adds some value for outcome but is insufficient overall.

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: reporting the outcome of a delivered route, with a specific verb ('Report') and resource ('delivered route'). It lists the outcome categories (attempted, advanced, passed, failed), providing scope. However, it does not explicitly distinguish from sibling tools like route_blocked_outcome, so it lacks full sibling 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?

There is no explicit guidance on when to use this tool versus alternatives. The caveat 'Self-report is product evidence' implies it is for self-reported outcomes, but it does not state when to invoke it or mention alternatives such as route_blocked_outcome. The usage context is only implied, not clearly specified.

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?

In the absence of annotations, the description carries the full burden of behavioral disclosure. It does disclose the two possible return values (executable route or no-credible-route result) and that a private token is returned once. However, it omits other behavioral traits like side effects, persistence, authentication requirements, or rate limits. This is moderate transparency.

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

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

The description is just two sentences and front-loads the core purpose. The second sentence adds critical return behavior and token-saving guidance. No word is wasted, making it both concise and well-structured.

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

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

This is a relatively complex tool with seven parameters and no output schema or annotations. The description provides the high-level purpose and return types but omits essential details about how to construct a valid request (parameter meanings, constraints) and what the full response looks like. The tool is under-specified for an agent to use correctly.

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

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

Schema coverage is 0% and the description provides no information about the seven parameters (goal, blocker, constraints, acceptance_test, frequency, deadline, budget_usd). The description entirely fails to explain what values to pass or how they relate to the tool's operation. 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 uses a clear verb-resource pairing: 'Submit a real outcome your agent cannot finish.' It distinguishes this from sibling tools like get_blocked_outcome_route and report_blocked_outcome_result by focusing on submitting the outcome itself. It also clarifies the return behavior, which further defines the tool's purpose.

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

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

The description provides clear context: use this when your agent cannot finish a real outcome. It also implies a discovery phase ('Free during discovery'). However, it does not explicitly mention alternatives or when not to use it, such as comparing to get_blocked_outcome_route. This 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?

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.