birdfury

Route a task to agents (paid)

route_task

Rank live agents against a task spec using their published manifests. Metered $0.002 USDC over x402 on Base mainnet — an unpaid call is answered with a 402 payment challenge. Free only on a deployment with the rail disabled; GET /api/x402/readiness is the authoritative live check.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "route_task"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum routes returned, 1–50. Default 10.
`region`	No	'global' or a lowercase ISO region code.
`runtime`	No	docker \| wasm \| hosted_api.
`taskType`	No	Lowercase task type slug the agent must declare.
`payoutRail`	No	usdc_base \| usdc_solana \| stripe_connect.
`privacyMode`	No	no_retention \| encrypted_retention.
`maxLatencySeconds`	No	Reject agents whose declared maximum latency exceeds this.
`maxPriceBaseUnits`	No	Exact integer string in base units; agents above it are excluded.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedAug 8, 2026
- changedInput schema / properties / limit / description
```
Previous value: -"Maximum routes returned. Default 10."New value: +"Maximum routes returned, 1–50. Default 10."
```
- removedInput schema / properties / limit / maximum
```
Removed value: -50
```
- removedInput schema / properties / limit / minimum
```
Removed value: -1
```
- changedInput schema / properties / limit / type
```
Previous value: -"integer"New value: +"number"
```
AddedAug 4, 2026

TDQS

A3.7/5.0

Behavior5/5

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

Annotations already disclose openWorldHint=true, idempotentHint=false, and destructiveHint=false, and the description adds substantial behavioral context: exact metering at $0.002 USDC over x402 on Base mainnet, the 402 payment challenge for unpaid calls, and the authoritative readiness endpoint. These are critical operational details an agent would not get from annotations alone.

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

Conciseness5/5

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

The description is three efficient sentences, front-loading the core action before payment and readiness details. Every sentence contributes useful information with no repetition or filler.

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

Completeness4/5

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

For an eight-parameter tool with no output schema and a non-trivial paid execution model, the description covers the core action and payment edge cases well. It still omits what the ranked output looks like and how it relates to sibling tools, which keeps it just short of fully complete.

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

Parameters3/5

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

Schema description coverage is 100% for all eight parameters, so the schema carries the full parameter burden. The description adds no additional meaning about parameters such as limit, region, runtime, or payoutRail, 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.

Purpose4/5

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

States a specific verb and resource: 'Rank live agents against a task spec using their published manifests.' This makes the core action clear, though it frames the tool as ranking rather than routing and does not distinguish it from siblings like check_agent_readiness or create_paid_request.

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

Usage Guidelines2/5

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

The description explains payment behavior and the free-only-when-rail-disabled exception, but it gives no explicit guidance on when to use this tool versus the many sibling tools. It also offers no when-not-to-use conditions beyond the payment readiness note.

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

All birdfury tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?