Scraping MCP token usage: formats, tool count and failures

An agent with a scraping MCP server spends tokens in four places: the tool descriptions loaded into each session, the page content each call returns, the snapshots a browser server sends after each step, and the error messages when a fetch fails. Most "the agent ran out of context" problems come from one of these. This guide shows what to check in each and which controls the common servers document, as of 2026-10-27.

Formats

The same page can cost very different amounts depending on the format:

• Full HTML keeps scripts, navigation, footers and attributes. It is useful when the markup itself is the data, and wasteful for reading.
• Markdown of the main content keeps headings, lists, links and code blocks and drops the rest. It is the best default for reading, summarizing and citing.
• Plain text drops structure too. It is fine for classification or a yes/no check.
• Accessibility snapshots describe page elements and their roles so a browser server can click them. Playwright MCP uses them deliberately: they are what make reliable interaction possible. For reading, they carry more than you need.

What the servers document: Scrapling's extraction returns Markdown, HTML, text or an AI snapshot, with main-content-only as the default. Jina's read_url returns Markdown. Live Web Data API's get_page_contents returns Markdown, text or HTML, with a verbosity setting that keeps only the main content by default.

Size caps

A cap stops one very long page from filling the window. Look for it in the tool parameters, not in the marketing page:

A cap is a blunt tool. Combine it with main-content extraction so the characters you keep are the useful ones.

Tool count and context cost

The MCP specification has servers list their tools with a name, a description and an input schema. What the client does with that list differs. A client that passes every definition to the model up front spends context on every registered tool in every session, whether the model calls it or not. Claude Code defers MCP tool definitions by default through tool search: only tool names and server instructions load at session start, and a definition loads when the model needs it (checked 2026-10-28). A large tool surface costs less there, so read this row together with the client you use.

If two servers are connected, both lists load, as names only in a client that defers them. A common pattern is a small read-only server enabled by default and a browser server enabled only for interaction tasks.

Failure semantics

Failures cost tokens twice: once for the error text, and again when the model retries something that cannot succeed. Two properties help:

1. Errors that say what to do. "The page took too long; try again later or use another source" lets the model move on. A bare status code invites retries.
2. Clear cost on failure. Under Firecrawl's pricing, a page that returns an error status such as 403 or 404 still costs one credit. Live Web Data API charges nothing for failed or blocked requests and ends each such error with "No credits were charged." Self-hosted servers cost your compute either way.

Checklist

• Markdown of the main content is the default format.
• Every page read has a cap.
• Only the tools the job needs are registered.
• Errors map to one clear next step.
• You know what a failed call costs.
• You tested one long page and one 404 before a long run.

For the full rubric, see the rubric guide. For the shapes of the bill behind these calls, read the pricing models guide.

If a content API fits

Live Web Data API appears in these tables. Its MCP server reads one public page per call and does not render JavaScript, crawl or search. To see its tool parameters, read the MCP docs.