Skip to main content
The Model Context Protocol (MCP) is an open standard that lets AI agents connect to external tools through a uniform interface. fetchbean hosts an MCP server at https://api.fetchbean.com/mcp, so any MCP-compatible agent gets the entire fetchbean catalog — web search, page reads, weather, and every connected provider — over a single connection.

​
Four meta-tools, not hundreds

The catalog is large and grows constantly, so the server does not enumerate every capability as its own MCP tool. It exposes exactly four meta-tools. An agent finds a tool by task, then runs it:

discover

Find the right tool for a task. Returns ranked tools, each with its provider, endpoint, a terse params list, and whether a connected account is needed. Always call this first.

describe

Get the full input JSON Schema, an example call, cost, and connection info for one tool. Call it before run when you are unsure of the arguments.

run

Execute a tool by its provider and endpoint, passing input that matches its schema. Spends prepaid credits.

request

Log a request for a tool fetchbean does not have yet, at the moment you needed it. Free, and attributed to your org.
The same discovery and execution flow is available over HTTP: MCP discover corresponds to GET /discover, and MCP run corresponds to POST /v1/run. describe is MCP-only; HTTP callers can get full schemas from GET /catalog or the OpenAPI specification.

​
Configuration

Add the server to your agent’s MCP configuration. It speaks Streamable HTTP and is stateless, so there is no local process to run:
Your key goes in the X-API-Key header, configured once — the agent never handles it per call. Create a key under API Keys in the dashboard.

​
What needs a key

Discovery is open; execution is not. Because discover and describe are open, an agent can explore the catalog and inspect a call’s fixed price or metered pricing model before it runs.

​
A typical exchange

An agent that needs current web results works through the tools in order:
1

discover

Call discover with q: "web search". The response ranks matching tools and returns the provider and endpoint for each.
2

describe (optional)

If the arguments aren’t obvious from discover, call describe with that provider and endpoint to get the full input schema and an example.
3

run

Call run with the provider, endpoint, and an input object matching the schema. You get the registered operation’s provider-specific result, without the normalization applied by provider-independent HTTP tools.
Read tools fetch; write tools change state in the connected service. run will execute either, so confirm intent before running a write.

​
Providers that need your own account

Operations that act on your account require a provider connection. discover flags these in its results, and describe names the provider to connect. Connect it once from the dashboard and its registered tools become callable through run with no change to your agent. See Connections. A run against an unconnected provider fails with credential_required and is billed zero.

​
Asking for what isn’t there

When an agent needs a tool the catalog doesn’t have, request records it at the point of need instead of failing silently. need is the public-safe ask; anything proprietary belongs in context, which only the fetchbean team can see. Requests default to private — set visibility: "public" to add one to the public board and collect votes.
Inspect the exact tool definitions the server serves, without a key, at GET https://api.fetchbean.com/mcp/tools. It returns the same four definitions the hosted endpoint uses, so a local bridge can never drift from it.