Built-in web search vs wiring a search API into your agent

Built-in web search means your agent calls web__search and web__scrape on the MCP server it already signed into, with no search provider account, and pays per request from the organization's credits. Wiring a search API means you hold a provider key, build the tool yourself, and get every parameter the provider exposes. Both are reasonable. They fit different situations.

What do the built-in web tools return?

web__search returns ranked sources, each with a title, URL, published date, author and a short text snippet. It does not synthesize an answer; the agent reads the sources. num_results runs from 1 to 25 with a default of 8. category biases results toward one content type: company, research paper, news, pdf, github, tweet, personal site, linkedin profile, or financial report. include_highlights adds query-relevant sentences per result, and livecrawl forces a fresh crawl instead of the index cache.

{
  "name": "web__search",
  "arguments": { "query": "MCP authorization RFC 9728", "num_results": 5, "category": "research paper" }
}

web__scrape returns the clean text of one https page. max_characters defaults to 50,000 and is capped at 200,000. IP literals, loopback and internal hostnames are refused before any request leaves CoreSpeed. There is no multi-page crawl: search first, then scrape the pages that matter.

A third group reads specific sites as structured records: web__google_search for Google's own results page with People Also Ask and an optional AI Overview, web__google_maps_search and web__google_maps_reviews, web__airbnb_listings, web__tripadvisor_search and web__tripadvisor_reviews, web__amazon_products, web__zillow_listings and web__zillow_property. These run a live collection that takes 10 to 60 seconds, accept timeout_seconds (default 50, max 240), answer with a complete flag and a count, and bill only what was gathered. A collection that found nothing answers timeout and bills nothing. The full parameter list is on the web page.

What do you get from a direct provider key?

The full surface of that provider. Every parameter it exposes, every index feature, its own SDK and its own documentation. You pick the provider, you hold the billing relationship, and you set the rate limits with them directly. If a provider offers a crawl across many pages or a filter the built-in does not expose, a direct integration is the way to reach it.

The costs are the ones every custom tool carries. You write the tool and register it in each client. The provider key lives in the agent's config or environment, which is the custody problem connectors exist to avoid. Spend shows up on the provider's invoice, apart from the organization's ledger, with no per-key cap unless you build one. And the calls never appear in the activity trail, so the record of what the agent read is whatever you log yourself.

When is the built-in the right choice?

When the job is grounding: find current sources, read the ones that matter, cite them. When every client on the team should have search without each person onboarding to a provider. When cost should land in the same ledger as everything else the agent does, under the same monthly cap on the API key and the same organization threshold. web__search costs 14 credits per request covering up to 10 results, and web__scrape costs 5 credits per page; a failed request is never charged. The billing page has the rest.

It is also the right choice when the agent is unattended. A nightly job you run with an agent key gets search with no extra secret to hold, and its reads are attributed to that agent in Dashboard → Activity.

When should you wire a provider directly?

When you need a parameter the built-in does not expose. When the task is a crawl across many pages rather than search followed by a handful of scrapes. When your organization already has a contract with a provider, or wants a direct billing relationship at its volume. When search results have to carry provider-specific metadata your pipeline depends on.

The two combine without friction. A local search tool can sit beside the CoreSpeed server in the same mcpServers map. And one rule applies to both: content fetched from the web is untrusted. Pages can carry instructions aimed at the agent, so keep the client's confirmation on for writes when several servers are connected, as the security notes on the MCP server page describe.

FAQ

Does web__search answer my question? No. It returns ranked sources with snippets. The agent reads them and answers. Hand a source URL to web__scrape to read it in full.

Can the built-in crawl a whole site? No. There is no multi-page crawl. Search to discover pages, then scrape each one you need.

How do I turn web off for one person? Dashboard → Tools, as a member setting. It unregisters every web__* tool from that member's tools/list; a member setting only narrows what the org allows.

What happens when a listing collection runs out of time? The rows gathered so far come back with complete: false, and only those are billed. A collection that found nothing answers timeout and bills nothing.

Does the built-in need any account of mine? No. The web tools run on CoreSpeed's own supplier accounts. There is nothing to connect.