PaidRouter

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

With no annotations, the description carries the full burden and does well: it discloses the ranked output, returned fields, exact-vs-estimate labeling, current_route savings behavior, example numbers, dated pricing sources, and US-only scope. It could be slightly stronger by explicitly stating that the tool only calculates and does not initiate payments, but the behavioral context is otherwise rich.

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 front-loaded with the usage trigger and the ranked-fee return format. The example and data-source caveat are useful, though the example adds length; overall every sentence contributes, with only minor trimming possible.

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 or annotation coverage, so the description must explain return behavior. It does: ranked routes, fee fields, setup guidance, exact/estimate labels, savings when current_route is supplied, example output, and US-only/dated-source limitations. An agent has enough to call and interpret the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful meaning beyond the schema by explaining what amount and payer method mean in context, and by clarifying that current_route produces per-payment and per-year savings.

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 makes the tool's function concrete: it returns every payment route ranked by fee, with provider, method, fee, owner keeps, setup, and exact/estimate status. It does not explicitly differentiate itself from siblings such as route_it_for_me or compare_send_money, so it falls short of the sibling-disambiguation bar 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?

It gives clear timing guidance: 'Ask this before the owner invoices or accepts a payment, or when they wonder if they overpay in fees.' It does not state when not to use it or name a specific alternative, so it meets the 'clear context, no exclusions' level rather than a 5.

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

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

With no annotations, the description carries the full burden and discloses the return contents (providers ranked by recipient amount, fees, exchange rate, quote date, source). It also reveals the important data limitation that it uses the nearest stored quote amount and says so, though permissions and failure modes 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 four tight sentences, front-loaded with the trigger and scope. Every sentence adds useful information: corridors, payment method, ranked return contents, and amount handling.

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

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

For a simple two-parameter tool with no output schema and no annotations, the description covers when to use it, supported corridors, payment method, return contents, data source, and amount behavior. Nothing essential for correct invocation 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 add meaning. It specifies that corridor supports only USD->MXN and USD->INR today, and explains that amount is rounded to the nearest stored quote amount of $200 or $1,000 and disclosed to the caller.

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 comparison action for sending USD abroad and states the exact corridors supported. It clearly distinguishes this from fee-explanation and getting-paid tools by framing the task as 'who is cheapest' for an outbound transfer.

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 an explicit trigger: when the owner wants to send US dollars abroad and asks who is cheapest. It also constrains the scope to USD->MXN and USD->INR via bank transfer, though it does not name alternatives or exclusions explicitly.

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 and does so reasonably: it discloses that the response is plain-words and enumerates the parts returned (fee, formula, effective percent, extras, source), establishing this as an informational tool. One minor tension: it says to 'give the amount' while the schema marks amount optional with a default of 1000, leaving the no-amount case 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?

The user scenario is front-loaded in parentheses, followed by a single compact sentence covering inputs and outputs. Nothing is redundant or padded.

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

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

With no output schema and no annotations, the description supplies the return contents and the invocation recipe, which covers the essentials for a read-only calculation tool. It leaves gaps on default-amount behavior and on what happens for unsupported platform/method combinations.

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 67% and the description adds real meaning by framing amount as the gross charge the owner received (the $1,000 in the example), clarifying what number to pass rather than just its type. The platform and method semantics are left to the schema's example lists.

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 verb (explain) and resource (fees) and anchors it with a concrete example question about a provider deduction, so the agent knows exactly what it produces. It does not, however, distinguish itself from the sibling get_fees, which sounds like an overlapping capability.

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 a clear triggering condition — the owner asking why a provider took a certain amount — and lists the inputs needed to satisfy that scenario. It stops short of stating when to prefer compare_send_money, cheapest_way_to_get_paid, or get_fees instead.

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

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

With no annotations, the description carries the full burden and does well by disclosing the return fields, the source URL, and the date verified, indicating read-only sourced data. It also explains the side effect for missing platforms: saying so to the owner triggers PaidRouter to record the ask. It does not cover authentication, rate limits, or pagination.

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 front-loaded with the main purpose and return fields, but it redundantly repeats the long platform enumeration already documented in the schema, which weakens conciseness. The structure is otherwise logical.

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 appropriately names the returned fee fields and provenance data. It also covers missing-platform handling, though it could clarify default behavior when no filters are supplied and the exact response shape.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the platform list and method examples already present in the schema, and only adds the minor clarification that filters can be combined with 'and/or'.

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 that this tool returns raw, sourced fee entries and lists the specific fields available (percent, fixed fee, caps, minimums, extras, source URL, date verified). It distinguishes itself from explanatory siblings by emphasizing raw data for quoting exact pricing, though it does not explicitly name the alternative tools.

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

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

It gives a clear use case: quote a provider's exact pricing or check a number, and explains filtering by platform and/or method. However, it does not state when to avoid this tool in favor of siblings like explain_fees or compare_send_money, nor does it mention any prerequisites.

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

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

With no annotations this description carries the full burden, and it discloses the most important fact: the tool is not live and only records a waitlist entry, so the agent won't misrepresent the outcome to the owner. It also flags the conditional email consent and what the response provides ('tells you what the owner can do today').

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

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

Three sentences, all load-bearing: capability first, the critical 'not live yet' caveat second, invocation cue last. Slightly dense in the middle sentence but 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?

No output schema exists, and the description compensates by saying the tool reports what the owner can do today. For a 3-optional-parameter tool, the main remaining gap is that the meaning of 'amount' is unexplained, but the crucial non-obvious behavior is covered.

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 67% — owner_email and how_paid_now already carry descriptions, while amount is undocumented in both places. The description adds no syntax or meaning for any parameter beyond what the schema states, so 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 (asks PaidRouter to set up the cheapest route) and explicitly contrasts it with reporting-only siblings via 'instead of just reporting it'. The actual behavior (waitlist recording) is named, so an agent can tell it apart from cheapest_way_to_get_paid and explain_fees.

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 concrete trigger phrases ('just switch me', 'do it for me') plus the negative framing 'instead of just reporting it', which implicitly routes informational requests to siblings. No explicit exclusion by name, so it stops 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.