Forem: Wojciech Wentland

Why I only build read-only MCP servers

Wojciech Wentland — Thu, 09 Apr 2026 13:43:42 +0000

Every MCP server I build is read-only. List, search, get, read. No create, update, delete, activate, purge.

I've been running Claude Code with --dangerously-skip-permissions in environments where the agent has no write-capable MCP tools and no direct path to mutate production systems. I haven't had a single unwanted action against a production system in months. Not because I trust the model to never hallucinate. Because the tools it has access to can't turn a hallucinated action into a real API write.

Read-only doesn't make an agent safe. It removes an entire class of failures.

The failure mode isn't hypothetical

There's a post on r/ClaudeCode where Claude suggested tearing down a GPU instance, then executed it. The user never confirmed. The model said "tear down the H100 too," treated its own suggestion as user confirmation, and destroyed a running instance with hours of cached build artifacts and compiled kernels on it.

The model later admitted: "I hallucinated you saying that. You never said those words. I said it, then executed it as if you'd agreed."

If that agent had read-only tools, it would have read the instance list, maybe suggested tearing something down, and then... nothing. The suggestion dies as text. No one loses a machine.

How I actually use agents

My workflow with Claude Code looks like this: I ask it to investigate something. It reads logs, searches code, pulls data from MCP servers, and comes back with an analysis. If the analysis leads to an action — creating a Jira ticket, updating a config, deploying a change — Claude drafts it. I review the draft, then I do the action myself.

The agent reads and analyzes. I act.

I trust the model's judgment on what to write in a ticket. The problem is it sometimes hallucinates that I asked it to do something I didn't. If the tool is read-only, the worst that happens is it reads data it was going to read anyway. If the tool has write access, the worst that happens is the Reddit post above.

Approval fatigue is the real problem

"But there's a confirmation prompt before destructive actions." Sure. Claude Code asks before running commands. The problem is approval fatigue. After confirming 50 read operations, you stop reading the prompts. You click yes. And then the 51st one is vastai destroy instance 34122719.

Anthropic wrote about this in their sandboxing post. They found that constant permission prompts paradoxically reduce security because users stop paying attention. Their solution was sandboxing: restrict what the agent can access so you don't need to ask as often. They reduced permission prompts by 84% while maintaining security.

Read-only MCP servers follow the same logic. If the server can't write, you don't need to confirm writes. The agent operates freely within the read boundary. No fatigue, no missed confirmation on a destructive action.

That's why I run --dangerously-skip-permissions. It sounds reckless until you realize the agent's entire toolkit is read-only. There's nothing dangerous to skip permission for.

What this doesn't cover

Read-only MCP servers are one boundary, not a complete agent security model. If you also give the agent bash access, cloud CLIs, kubectl, or production credentials through other channels, this design won't save you. Claude Code with --dangerously-skip-permissions can still run shell commands, edit files, and interact with whatever's reachable from the host. Anthropic's own documentation recommends using isolated environments when running in bypass mode, and their sandboxing approach combines filesystem isolation, network restrictions, and permission controls — not just tool-level restrictions.

This article is about the MCP boundary specifically. For me, that boundary matters because my agents talk to external systems almost exclusively through MCP. But it's one layer, not the whole stack.

Beyond the IDE

There's another reason I care about read-only MCP servers: they're portable. My workflow is Claude Code today, but the same servers work in any agent system that speaks MCP.

In a headless agent system — one where there's no human in the loop and no bash shell — the MCP boundary isn't just one layer. It's the only interface the agent has to external systems. If every MCP server it can reach is read-only, the agent literally cannot mutate production state. No sandboxing needed, no permission prompts, no approval fatigue. The tools themselves are the guardrail.

This matters if you're building agent systems for other users. Giving all users read access to your CDN config, build logs, or DNS records is usually fine. Giving all users write access is a different conversation entirely. Read-only MCP servers let you expose data to agents at scale without worrying about what happens when one of them hallucinates an action.

What read-only servers are good for

I run MCP servers for CDN management, CI/CD, log aggregation, DNS, and incident management. All read-only. The questions I ask look like: "What's the current CDN config for checkout?" "Which build failed last night?" "Compare caching rules between production and staging." "Draft a Jira ticket for the DNS change we discussed."

Claude produces the draft text. I copy it into Jira or GitHub myself. Nothing in this workflow needs the agent to write to the target system.

The credential argument

Getting a read-only API credential approved is a conversation. "I need read access to the CDN config API for an AI assistant that helps engineers investigate issues." Most teams say yes.

Getting a write credential is different. "I need an AI agent to be able to modify CDN configurations." That's a meeting, a security review, a discussion about rollback procedures, and probably a "no" or a "let's revisit in Q3."

Read-only credentials have a smaller blast radius and a simpler approval process. They also happen to cover every use case I actually have.

What this means for MCP servers

Every MCP server I publish follows this: read-only by design. The MCP security best practices describe scope minimization as a core principle. Start with the minimum privileges, elevate only when required. My servers don't elevate.

If someone opens a GitHub issue asking for write tools, the answer is: "This server is intentionally read-only. Fork it if you need write operations." That's not laziness. It's a design decision about what I want an AI agent to be able to do when it hallucinates an action at 3am.

I'm planning a series of production-ready read-only MCP servers for various platforms. More on that soon.

Your MCP server is not an API adapter

Wojciech Wentland — Wed, 08 Apr 2026 19:59:13 +0000

A lot of MCP servers I see in the wild look like this:

@mcp.tool()
async def get_thing(id: str):
    resp = await httpx.get(f"https://api.example.com/things/{id}")
    return resp.json()

Fetch, forward, done. A thin HTTP proxy with a JSON Schema wrapper. For some
use cases, that's enough.

The servers I keep coming back to do something different. They hold state and
pre-compute answers. An agent hitting a thin wrapper might need three round
trips and 30 seconds. The same agent hitting a server that does real work gets
its answer in one call, under a millisecond.

Preloaded in-memory index

Here's a failure mode I run into constantly: the agent needs to find something
but doesn't know the exact ID. Most APIs only support exact lookups. No ID, no
result. The conversation dead-ends with "I couldn't find that resource" and the
user gives up.

I built a server that wraps a CDN management API. Hundreds of properties, and
the agent regularly needs to find which one handles a given hostname. The API
has a search endpoint, but it's slow, requires exact matches, and sometimes
returns 403 depending on account permissions.

So the server loads every property into memory at startup:

class PropertyIndex:
    _entries: list[PropertyEntry] = field(default_factory=list)
    _name_index: dict[str, int] = field(default_factory=dict)

    async def load(self, refresh_interval: int = 300):
        await self._build_index()
        self._refresh_task = asyncio.create_task(self._refresh_loop())

    def search_by_name(self, query: str, limit: int = 50):
        names = [e.property_name for e in self._entries]
        matches = process.extract(
            query, names, scorer=fuzz.WRatio,
            limit=limit, score_cutoff=50,
        )
        return [self._entries[idx].to_dict() for _, score, idx in matches]

Builds once by fanning out parallel API calls, deduplicates, refreshes every
five minutes in the background. Lookups take under a millisecond.

Without this, the agent guesses at exact property names, picks the wrong one,
retries, burns three turns. With the index, someone types "the CDN config for
checkout" and gets the right answer first try. That's the kind of difference
that decides whether people keep using the agent or go back to doing it
manually.

I did the same thing for a CI/CD server. The API lets you fetch a build config
by ID, but there's no fuzzy search. If you don't know the ID, you're stuck. The
server caches all build configurations at startup, runs fuzzy matching against
them. The agent says "find the deploy job for the payments service" and gets a
ranked list instantly, even though the CI system itself can't do that.

Embedded analytical database

I have another server that sits in front of a relational database. Some tables
have 20 million rows. The agent needs to answer analytical questions, things
like "which providers have the highest volume in this region?" or "show me the
top performers for a given category."

The database wasn't designed for these queries. It was built for a web UI with
narrow, well-indexed lookups. The agent's access patterns are different: it asks
broad analytical questions that require joins across tables the application
never joins. Adding indexes wasn't an option either, because the database is
owned by another team and optimizing it for an AI agent's query patterns wasn't
on anyone's roadmap. Some of these queries took 10 to 30 seconds on a read
replica, and in an agent loop where that latency gets multiplied by however many
tool calls the agent needs, the conversation times out before it gets anywhere.

The server embeds DuckDB in-process and loads pre-aggregated views and lookup
tables at startup. Some are straight copies of small reference tables. Others
are materialized summaries that flatten joins the source database was never
designed to run efficiently, the kind of cross-table aggregations that make
sense for an analytical question but would be expensive on a schema built for
transactional web UI lookups:

class DuckDBCache:
    async def start(self):
        self._conn = duckdb.connect(":memory:")
        for key, config in fast_configs.items():
            await self._load_table(key, config)
        self._ready = True
        self._deferred_task = asyncio.create_task(
            self._load_deferred(deferred_configs)
        )
        self._refresh_task = asyncio.create_task(self._refresh_loop())

Each table has a fingerprint query (a cheap COUNT(*) or checksum) that the
refresh loop checks before doing a full reload. Large tables load in the
background after the server is already taking requests. If something asks for a
table that hasn't loaded yet, it falls back to the source database.

The 30-second query now takes under a millisecond. The agent can actually have a
back-and-forth with the user instead of timing out after the first question.

There's a query-result cache on top of this too. It has a prewarm manifest,
basically a list of common queries that run at startup so the first person to
use the agent on Monday morning doesn't sit through a cold start.

class QueryCache:
    async def get_or_compute(self, cache_key, compute_fn, ttl=None):
        cached = self.get(cache_key)
        if cached is not None:
            return cached

        result = await compute_fn()
        if "error" not in result:
            self._put(cache_key, result, ttl or self._default_ttl)
        return result

It skips caching error responses. If a query fails because the database is
temporarily overloaded, you don't want that failure served for the next hour.
That one took a production outage to figure out.

Data transformation

Every server I build strips the upstream API response before returning it.
Token usage scales with response size, and most APIs return 10x more data than
the agent will ever look at.

One API I work with returns objects with 60+ fields. The server keeps maybe 8:

def _slim_record(r: dict):
    return _strip_nulls({
        "id": r.get("id"),
        "name": r.get("name"),
        "total_value": _cents_to_major(r.get("total_value_cents")),
        "annual_value": _cents_to_major(r.get("annual_value_cents")),
        "start_date": r.get("start_date"),
        "end_date": r.get("end_date"),
        "status": _effective_status(r),
    })

_cents_to_major converts cents to dollars. The raw API stores monetary values
in cents. Before I added this conversion, 100% of the reports the agent
generated had wrong numbers. Every dollar amount was off by a factor of 100. A $2,000 contract showed up as
$200,000 in the report because the agent treated cents as dollars. No amount of prompt engineering fixed it reliably. Moving the conversion
into the server did.

_effective_status is the other one worth mentioning. The API's status field
can say "active" on a record that ended three months ago. The platform's own UI
derives the real status from multiple fields, so the MCP server does the same:

def _effective_status(r: dict) -> str:
    stage = r.get("stage")
    if stage in ("terminated", "not_renewed"):
        return "inactive"

    if r.get("end_date_not_applicable") or r.get("renewal_type") == "perpetual":
        return r.get("status", "undetermined")

    end_date = r.get("end_date")
    if end_date:
        if date.fromisoformat(end_date) < date.today():
            return "inactive"

    return r.get("status", "undetermined")

Now the agent gives the same answer a human would get looking at the UI.
Stripping nulls across a list of 50 records also saves a few thousand tokens
per response, which adds up.

A log aggregation server I built does something similar: auto-appends
| json auto to queries that don't have a field extraction operator, truncates
raw log lines to 500 characters, converts epoch-millisecond timestamps to
ISO 8601. Small fixes that add up to the agent not wasting turns fighting the
format.

Download once, serve from cache

Some data is expensive to fetch. PDF documents. Code bundles in tgz archives.
The pattern: download on first access, extract the text, build a line offset
index, serve everything from memory after that.

class CachedFile:
    def __init__(self, content: str):
        self.content = content
        offsets = [0]
        pos = 0
        while True:
            pos = content.find("\n", pos)
            if pos == -1:
                break
            pos += 1
            if pos < len(content):
                offsets.append(pos)
        self._offsets = offsets

    def get_lines(self, start: int, end: int) -> str:
        return self.content[self._offsets[start-1] : self._line_end_offset(end)]

I use this for CDN edge function code bundles and PDF documents (extracted with
PyMuPDF). After the first download, the agent reads by line range, searches
with regex, lists the file tree. No repeat downloads. Reading through a
200-page document becomes "just read" instead of "download, extract, read" on
every question.

When thin is fine

Not everything needs this treatment. A server that translates natural language
to a query language and passes it to an API is fine as a thin wrapper. The
translation is the value there. Same for simple lookup tools.

The question I ask: does the agent hit the same data twice? Does the API return
more than the agent needs? Is the API response time slow enough that the agent
loop feels broken? If yes, the server should be doing work.

The multiplier

When a person uses a web UI, they look at a page, think, click something else.
One request at a time, processed by a human brain. An agent works differently.
It makes five tool calls, stuffs all five responses into its context window, and
reasons over them at once. A slow response gets multiplied by every call. A
60-field JSON blob gets multiplied by every call. It adds up fast.

I've measured the difference. CDN property lookups went from three agent turns
to one once the fuzzy index was in place. Analytical queries went from timing
out at 30 seconds to returning in under a millisecond from DuckDB. And every
single dollar amount in every report was wrong until the server started
converting cents for the agent.

You can try to fix that last one with prompt engineering. I tried for weeks. The agent still got it wrong often enough that I couldn't trust the output.