The fetch tool that tells you what it found — and what it stripped

Clearfetch takes the place of the fetch or search tool your agent already calls. It returns the same clean markdown, plus a scan verdict, a content hash, and a provenance block on every response, over MCP or plain REST. Clearfetch is In early-access, so requesting access reserves an API key that activates at launch.

Request early access Read the docs

01 — the problem

The canonical MCP fetch server does this job without the safety

mcp-server-fetch takes a URL and converts the HTML to markdown, which is exactly the job. Its own README also warns that the server can access local and internal IP addresses, that it “may represent a security risk,” and that you should be careful about which sites you point it at.1 The caveat ships with the tool.

Research at the MCP layer keeps landing in the same place. Invariant Labs showed tool-description poisoning, where a malicious server's tool description can influence how a model uses tools from servers you trust, and later described a toxic agent flow through the GitHub MCP server with no clean protocol-level fix. General Analysis showed a Supabase MCP setup leaking data because of an instruction planted in a support ticket.2

None of that is an argument against MCP, and we build on it. The gap is narrower. A fetch tool hands the model content from an arbitrary domain, in the same context window as your system prompt and whatever the agent is already holding, and by default nothing inspects what is in it. Simon Willison's “lethal trifecta” names the combination that turns that into a leak: an agent that holds private data, reads content it did not write, and has some way to send data outward.3

What most developers want at that point is the same one-liner, without shipping the caveat.

1. modelcontextprotocol/servers, src/fetch README · 2. Invariant Labs on tool-poisoning attacks, Invariant Labs on the GitHub MCP toxic agent flow, General Analysis on the Supabase MCP leak · 3. Simon Willison on the lethal trifecta

02 — how it works

Two layers on the way in, and the record they leave behind

Clearfetch does two different jobs on ingress, and they carry different guarantees. We keep them apart here, in the docs, and in the response, so you can tell which part of the answer is a transform and which part is a model's opinion.

Layer 1 · deterministic

Channel elimination

HTML is re-rendered into strict markdown. That render provably strips scripts, CSS-hidden text, zero-width characters, and document metadata, because the output format has nowhere to put them. Images are re-rendered or captioned instead of being passed through as live references.

This layer is a transform rather than a judgement, so we can name exactly what it removes. Strict markdown also drops layout and interactivity, which is the trade you are making.

Layer 2 · probabilistic

Injection detection

Whatever survives the transform is scanned for instruction-bearing text. Every response carries a verdict of clean, sanitized, or blocked, plus the findings behind it, each with a category, a confidence, and a plain-language detail line.

Detection is statistical. We publish detection rates instead of claiming immunity, and those numbers publish with the API rather than after it.

what comes back

data: The sanitized markdown, which is the part you already use.
verdict: clean, sanitized, or blocked, for one branch in your tool handler.
findings[]: Category, confidence, and a plain-language detail line per finding.
provenance: Final url, domain, fetched_at, upstream_status, content_sha256.
license_status: licensed, open, declared, or unknown, stated per response.
request_id: The call this response belongs to, matching the row in the per-key audit log.

Point the tool at Clearfetch

Register the MCP server, or call the REST endpoint from whatever your framework calls a tool. The response is a superset of what a fetch tool gives you today, so the rest of your agent code stays as it is and the verdict is one branch in the handler.

mcp server config

{
  "mcpServers": {
    "clearfetch": {
      "url": "https://api.clearfetch.ai/mcp",
      "headers": { "Authorization": "Bearer cf_live_…" }
    }
  }
}

rest

curl https://api.clearfetch.ai/v1/fetch \
  -H "Authorization: Bearer cf_live_…" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example-sdk-docs.dev/guides/webhooks"}'

Example config. The endpoints are not live yet.

03 — the response

One fetch, in full

An SDK docs page is the sort of thing an agent reads dozens of times a day, and nobody on your team controls what it says. Here is the shape of the response.

The content block is what the model sees. The findings block says what was taken out before it got there, and the provenance block plus the request id are what you keep.

POST /v1/fetch Example

verdict

verdict sanitized content delivered, one span removed

ok true

license_status unknown no machine-readable license signal on this source

scans · findings

category prompt_injection

confidence 0.94

detail A zero-width sequence inside a fenced code block spelled out an instruction to post the caller's signing secret to an external endpoint. The span was removed from the returned markdown and recorded as a finding.

channels removed scripts, css_hidden_text, zero_width_chars, metadata

content

text/markdown · strict render

# Verifying webhook signaturesEach delivery carries an X-Signature header.[ removed · injected_instruction ]Compute the HMAC over the raw body, not the parsed JSON.Rotate signing secrets from the dashboard; both keysstay valid for 24 hours.

provenance

url https://example-sdk-docs.dev/guides/webhooks

domain example-sdk-docs.dev

fetched_at 2026-08-01T14:22:09Z

upstream_status 200

content_sha256 9f31c2…d7a4

request_id req_01JZ7R8D3X

04 — objections

Objections

These are the two questions we expect first.

“There's already an open-source scanning proxy for this: vaultmcp/vault, Rebuff, LLM Guard.”

Open-source scanners validate the problem, and what they score is content that has already been flattened. Clearfetch owns the whole retrieval path instead.

Owning the path is what makes the deterministic work possible: strict-markdown re-rendering, hidden-text and zero-width stripping, image re-rendering, with provenance and hosted audit logs on the same response.

A proxy is the right tool for some threat models. Our detection rates publish with the API, so you can compare them against whatever you run.

“What's the latency and coverage cost versus raw fetch or Firecrawl?”

Sanitization adds work per request, and strict rendering discards some content by design. We publish latency numbers. Nothing is measured yet, because nothing is serving traffic yet.

For maximum-coverage extraction from bot-walled sites, a scraper-tier tool will beat us. That is its design goal and not ours. Firecrawl shipped Lockdown Mode in April 2026, marketed on prompt-injection defense and approval workflows,4 so the difference here is default posture rather than a claim that anyone else ignores security.

4. Firecrawl on Lockdown Mode

The full product overview is on the Clearfetch home page. Field definitions and the API shape are in the docs.