Why fetchira puts 24 providers behind six tools

An agent that does real work needs the web. It searches, reads pages, runs longer research and sometimes needs a page rendered in a browser. No single provider is best at all of that, and every provider has its own plan, its own limit and its own reset date.

Fetchira exists because wiring those providers in one by one breaks down fast. This post covers the two problems it solves and how the router decides where each call goes.

Every MCP server costs context

Of the 24 providers fetchira supports, 17 publish an official MCP server. Connect all 17 and they add about 95k tokens of tool definitions to every request, a median of 3.7k per server. That budget is spent before the agent has done anything.

The number comes from the tools/list JSON of each server at 4 characters per token. Server instructions and output schemas are not counted, so the real cost is higher.

The whole fetchira tool list is about 2.7k tokens. It has six tools:

• search for web, news, academic and Google results
• read to fetch any URL as clean markdown
• deep_research for long research runs
• browser for pages that need JavaScript
• create_image through a logged in ChatGPT, Gemini or Grok session
• usage for the modes, models and examples of each provider

The same six operations work over MCP and from the shell:

fetchira search "latest Rust release"
fetchira read "https://example.com"
fetchira usage serper

Free tiers run out at different times

The second problem is quota. Every free tier has a monthly, daily or one time allowance, and nobody tracks a dozen of them by hand. When one runs dry in the middle of a long task, the agent gets a 429 or a 402 and stops searching.

Fetchira keeps every limit in one place. You can add several accounts for the same provider and the router spreads calls across all of them. Some providers need no key at all: gdelt, keenable, jina and openalex work keyless. The three web providers, chatgpt_web, gemini_web and grok_web, use a browser login instead of an API key.

How the router picks an account

For each capability the router walks your providers in priority order and picks an account by its remaining allowance. Providers that cannot serve the request are skipped.

Where a provider reports its real remaining balance, fetchira caches it and routes on it, counting its own calls down between reads. For providers that report nothing, the built in quota is only an estimate. The provider’s own plan is always the authority.

Failures are handled by kind:

• A temporary rate limit causes failover to the next account and a retry delay. It is not treated as monthly exhaustion.
• A confirmed insufficient credit response triggers a separate quota check after a one minute cooldown. A fresh positive balance after a top up restores routing.
• If no account can serve the request, fetchira returns an error with the provider information it has.

You can change the order per capability:

fetchira priority search serper,tavily,exa
fetchira priority deep_research gemini_web,parallel

Passing provider over MCP, or --provider in the CLI, restricts a call to that backend. It does not fall back to a different provider, and it still obeys that provider’s limits. A returned session also pins the account, so a follow up cannot silently continue another conversation.

Try it

One command installs the binary and opens the dashboard on macOS and Linux:

npx -y fetchira

Add a provider, then connect your agent. fetchira install offers CLI only, MCP, or MCP with CLI fallback, and installs the matching skill in the agents you select. Restart the agent afterwards.

fetchira add serper --key KEY
fetchira install

The setup guide covers every install path, and the configuration guide covers accounts, quotas and troubleshooting.