AgentDrives

Choose a provider

choose_provider_for_task

Read-onlyIdempotent

Choose a payments, email, sign-in, scheduling or data provider for a task: send the task in a few plain words ('send an invoice') with filters if they matter, and get the SaaS, APIs, MCP servers and CLIs ranked by how far our agent got. Use search_tools when you have a name, domain or kind, and get_provider for one product. Read-only, no key needed; 5 results by default (up to 25), each with its agent level (0-5), the closest task and what happened, and next steps: sign-up, docs and MCP links.

Input Schema

Name	Required	Description
`task`	No	The task in plain words, e.g. 'send an invoice' or 'create a contact'. Send this or capability
`brief`	No	true (the default): each product with its next steps, under 8 KB for five; false: every field, with can_do, checks, connect, pay_rails and cite
`limit`	No	How many products to return, 1 to 25 (default 5)
`access`	No	signup_without_human: only products our agent signed up for and got into without a person (no browser login by a person)
`surface`	No	only products that offer this way for an agent to work them: api, mcp (an MCP server), cli or sdk; a comma list wants every one, e.g. mcp,cli
`category`	No	Only this category: an id or name from list_categories (e.g. 'invoicing')
`min_level`	No	Only products at this agent level or higher: 0 Read-only, 1 Needs a person, 2 Gets in, 3 Does the work, 4 Runs on its own, 5 Autonomous
`pays_with`	No	only products that take this way to pay: x402 or mpp (agent-native rails our drive met or the product documents) or card (a card checkout); a comma list takes any one, e.g. x402,mpp
`capability`	No	A capability of the shared vocabulary instead of task: its id (e.g. from GET /api/capabilities) or its name, e.g. 'Send a transactional email'
`self_signup`	No	true: only products our agent signed up for and got a key on its own, without a person

Output Schema

Name	Required	Description	Default
`result`	Yes	Choose a provider

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, but the description adds genuinely new context: no API key is needed, results default to 5 and cap at 25, and each result carries an agent level (0-5) plus a closest-task outcome. It does not discuss pagination or how ranking ties are broken, which keeps it below a 5.

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

Conciseness4/5

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

Three sentences, front-loaded with the purpose and the task-input hint before the sibling routing and result details. Slightly run-on in the first sentence, and 'Read-only, no key needed' partly restates the readOnlyHint annotation, but overall every clause carries information.

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

Completeness5/5

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

For a 10-parameter, filter-heavy discovery tool with an output schema, the description covers the input style, the filters' purpose, defaults and limits, and the result payload. An agent has enough to call it correctly without opening the schema.

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%, so the schema already documents all 10 parameters thoroughly. The description only reinforces the task phrasing ('send the task in a few plain words') and the default/max result counts, adding marginal meaning beyond the structured fields.

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

Purpose5/5

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

States a specific verb and resource ('Choose a ... provider for a task'), enumerates the domains covered (payments, email, sign-in, scheduling, data), and names the output shape (SaaS, APIs, MCP servers, CLIs ranked by agent progress). This is clearly distinguishable from lookup siblings like get_provider and search_tools.

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

Usage Guidelines5/5

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

Gives an explicit routing rule: use this tool with a plain-words task, use search_tools when you have a name, domain or kind, and get_provider for one product. The condition that selects each alternative is stated, so no inference is required.

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

All AgentDrives 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?