Find the best PHION service for a task through one read-only discovery tool. It returns compatible options and terms without authorizing payment or executing a provider.
Scored across 4 tools
find_or_quote_task and find_best_service_for_task are the same operation, one being an explicit compatibility alias, which forces an agent to reason about which entry point matters. authorize_and_execute_selected_task and verify_or_explain_result are clearly distinct, but verify_or_explain_result fuses receipt verification with failure triage into one tool. Descriptions do mitigate the overlap, keeping this at a middling score.
All names are snake_case and lead with an action verb, so the convention is predictable across the set. Minor deviation: several names are long compound verb phrases using 'and'/'or' (authorize_and_execute, find_or_quote, verify_or_explain), so the verb_noun pattern is not cleanly uniform.
Four tools is a sensible footprint for a routing/payment-broker server covering discover, execute, and verify. It is slightly inflated because one of the four is a pure compatibility alias for another, leaving three genuinely distinct operations.
The discover-to-execute-to-verify lifecycle is present, but there is no way to poll task or job status after execution, list available services, or handle refunds/cancellation of an authorized budget. verify_or_explain_result partially covers post-execution follow-up, yet dead ends remain for in-flight task tracking.
After find_or_quote_task selects a service, submit its input, an idempotency key and an explicit maximum atomic-USDC budget. The first call returns payment requirements without execution; an x402-aware client may obtain local approval and retry this identical MCP call with payment metadata. PHION never receives a private key and never expands the stated budget.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| dry_run | No | ||
| objective | Yes | ||
| target_service | Yes | ||
| idempotency_key | Yes | ||
| max_budget_atomic | Yes | ||
| acceptance_criteria | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint=true and idempotentHint=true, so the description's value-add is the two-phase payment handshake ('first call returns payment requirements without execution') and the trust guarantees (no private key held, budget never expanded beyond max_budget_atomic). It does not explain what dry_run does or whether a retry with mismatched payment metadata is rejected, which are the remaining behavioral unknowns for a paid mutation.
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: the trigger condition comes first, then the required payload, then the payment flow and trust constraints. No filler and no restatement of the tool name.
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 complex, open-world, 7-parameter tool with nested objects and no output schema, so the description should do more than describe the first response. It explains the payment-requirement return but leaves dry_run, acceptance_criteria semantics, and the shape of the final execution result undocumented.
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 carry all parameter meaning, yet it only covers input, idempotency_key and max_budget_atomic, and refers to target_service only obliquely ('its input'). Three parameters with real ambiguity, dry_run, objective and acceptance_criteria (a nested object array of up to 32 pointer assertions), are never mentioned, though the critical billing and dedupe fields are covered.
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?
Names a specific action (execute a service under an explicit budget) and anchors it to the sibling that must precede it (find_or_quote_task). An agent can distinguish this from find_best_service_for_task and verify_or_explain_result 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?
States the prerequisite clearly: it is called only 'After find_or_quote_task selects a service.' It also describes the two-step retry pattern. It does not, however, say when to prefer find_best_service_for_task or when to follow up with verify_or_explain_result, so routing among the remaining siblings is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compatibility alias for find_or_quote_task. Free, advisory and non-executing.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The outcome the agent needs, written naturally; do not translate it into a PHION service name. | |
| constraints | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by saying the tool is 'free, advisory and non-executing,' but it does not explain outputs, latency, rate limits, or how constraints affect 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?
The description is two short sentences with no wasted text, front-loading the compatibility-alias relationship and then adding behavioral qualifiers. It is appropriately sized for what it chooses to say.
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 a nested constraints object, no output schema, and open-world behavior, this description is far too thin. It establishes that the tool is a non-executing alias but leaves out what the agent gets back, how the alias differs operationally, and how constraints shape results.
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 only 50%, and the description itself says nothing about either parameter. The task parameter is documented in the schema, but the large nested constraints object is undocumented in both the schema and the description, leaving an agent without guidance on how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool only as a compatibility alias for find_or_quote_task, so its purpose is inferred from the name/title and sibling rather than stated directly. It does distinguish the tool from non-alias siblings by making clear it is a compatibility path, but it does not explain what 'find best service' actually returns or 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 phrase 'Compatibility alias for find_or_quote_task' hints at when it might be used, but there is no explicit guidance on when to choose this tool versus find_or_quote_task or the other siblings. 'Free, advisory and non-executing' clarifies constraints but not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here. Describe the desired result in ordinary language. PHION identifies the exact service, input schema, price ceiling and next call without charging or executing anything.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The outcome the agent needs, written naturally; do not translate it into a PHION service name. | |
| constraints | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds meaningful context beyond the readOnly/idempotent annotations: it explicitly promises nothing is charged or executed, and it enumerates what the response contains (service, input schema, price ceiling, next call) despite there being no output schema. It stops short of noting whether results are cached or how ambiguous tasks are resolved.
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 sentences, front-loaded with the routing cue ('Start here') and the invocation rule, with zero filler. Every sentence carries information an agent needs.
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 discovery tool with no output schema, describing the return payload is a genuine strength, and the no-charge/no-execute guarantee covers the main risk. However, the substantial constraints surface is left unexplained, which is the main omission for a tool with a nested 13-field options object.
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 `task` parameter is well covered by the description's 'describe the desired result in ordinary language', but the nested `constraints` object contains roughly a dozen sub-properties (privacy, maxPrice, deadlineMs, allowedPaymentRails, requireVerification, etc.) that are entirely undocumented in both schema and description. With 50% coverage and a complex nested object, the description should have explained at least the purpose of constraints.
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 action and outcome: given a natural-language task, it identifies the exact service, input schema, price ceiling and next call. The title plus 'Start here' makes clear it is the discovery/quotation entry point rather than an executor, though it never names the sibling tools it hands off to.
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?
'Start here' gives explicit ordering, and 'Describe the desired result in ordinary language' tells the agent how to invoke it versus how not to (no service-name translation). It implies a follow-up call but does not name authorize_and_execute_selected_task or explain when to prefer find_best_service_for_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a PHION receipt for free, or turn a structured failed status into one safe next action. This tool never charges, retries, or executes a provider.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | ||
| failure | No | ||
| receipt | No | ||
| sources | No | ||
| statusCode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety bar is partly met structurally. The description adds real value beyond them by guaranteeing no charges, no retries, and no provider execution, plus that verification is free — exactly the side-effect concerns an agent would have about a tool touching payments.
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 first and the safety guarantee second. No filler, nothing restated from 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 tool with a three-way branching input contract, undefined parameter meanings, and no output schema, the description leaves too much unanswered — notably what a verification response looks like and how statusCode/content/sources change behavior. Adequate only for the safety story.
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% across 5 parameters (including nested objects), so the description must carry the burden. It only gestures at 'receipt' and 'failure'; statusCode, content, and sources are never mentioned, and the anyOf requirement that exactly one of receipt/failure/statusCode be supplied is left undocumented.
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 two concrete modes with specific verbs and objects: verifying a PHION receipt and converting a failed status into a next repair action. The closing clause ('never charges, retries, or executes a provider') separates it from the execute sibling, 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 conditions are implied by the two described inputs (have a receipt → verify; have a failed status → get next action), but there is no explicit when-not guidance and no naming of authorize_and_execute_selected_task or find_or_quote_task as the alternatives for the cases this tool refuses to handle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
authorize_and_execute_selected_taskfind_or_quote_taskverify_or_explain_resultfind_best_service_for_task
Add one secure layer between your agents and this server.