Self-hosted scraping MCP server or hosted: what you trade

A self-hosted scraping MCP server runs on your laptop, your server or your cluster. A hosted one runs on a provider's infrastructure and you connect over a remote URL. Both put web pages into your agent's context. The difference is who does the operating work, who sees the data and which license applies.

What you run yourself

Three open-source options cover most self-hosting questions, all checked against their docs on 2026-10-27:

What you take on:

• Browsers. Crawlers and browser servers start real browser processes. Memory, crashes and version upgrades are now your problem.
• Network exposure. An HTTP transport listening on 0.0.0.0 without auth lets anyone on the network make your machine fetch pages. Scrapling's HTTP mode requires a token by default; keep it that way. Bind other servers to localhost unless you have a reason not to.
• Request-rate policy. Requests leave from your own machines, so setting polite per-site rates and stopping on 403 and 429 responses is your job. Careless use can get your address rate limited, which is a fair response from the site. Keep request rates polite and read the responsible scraping guide.
• Licenses. Apache-2.0 and BSD-3-Clause are permissive. AGPL-3.0 has obligations when you offer modified software over a network. Crawl4AI's README asks for attribution. Have someone read the license before you ship a product on it. This is not legal advice.

What a hosted server takes off your hands

A hosted server is a URL and a key. Firecrawl, Apify, Jina and Live Web Data API all offer remote MCP endpoints over Streamable HTTP. You skip browsers, patching and capacity planning, and you accept the provider's acceptable-use policy.

What you give up:

• Control over the code. You cannot patch a parser or add a tool.
• Data locality. The provider processes every URL and every page it returns.
• Cost predictability on your terms. You pay in the provider's unit: credits, events or pages. The pricing models guide compares those units.
• Access to everything. Reviewed sign-ups, restricted targets and acceptable-use rules limit what a hosted service will fetch. For most teams that is a feature, not a bug.

Privacy and data handling

Ask three questions of either option:

1. Where are URLs and content logged, and for how long? For self-hosted servers, check your own logs and the server's debug output. For hosted ones, read the privacy notice.
2. Who can call the server? A local stdio server is reachable only by the client that started it. A remote server is reachable by anyone with a key, so keys need rotation and per-environment scoping.
3. What personal data could pass through? Public pages can still contain names and contact details. Keep the agent away from pages that exist to profile people.

Decision checklist

Self-host when at least two of these are true:

• Content or URLs must not reach a third party.
• Someone on the team will own the server, with time set aside for it.
• You need to change the code or add tools.
• Your volume is high and steady enough that machines cost less than a per-page bill.

Use a hosted server when at least two of these are true:

• You want the agent reading pages today, not after an infrastructure project.
• Your volume is spiky or small.
• Nobody on the team has time to own a server, its updates and its request-rate policy.
• A short list of tools matters more than full control.

If a content API fits

Live Web Data API is a hosted single-page content API. Its MCP server reads one public page per call and does not render JavaScript, crawl or search. If a hosted reader fits, read the MCP docs. Sign-up is for businesses only. Only Business, Enterprise and Custom sign-ups are reviewed before checkout, usually within 1 business day.