DEV Community: DVARA

readOnlyHint isn't a permission: blocking a destructive MCP tool by policy

DVARA — Tue, 27 Oct 2026 10:53:46 +0000

MCP lets a tool describe itself. readOnlyHint: true says "I only read". destructiveHint: true says "I can delete or overwrite something". Clients can use those hints to decide when to ask a person before running a tool.

Two things go wrong with that in practice.

The hint is often missing. We looked at about 20,000 MCP tools for a report on MCP tool annotations. In Docker's MCP Catalog, 69% of tools that delete or overwrite something carry no hint at all.

The hint can be wrong. One server in that catalogue marked 15 delete tools as read-only, "delete ALL integrations" among them. The tools never set a hint, and a framework default filled in readOnlyHint: true for every one. The vendor fixed it within a week; the catalogue still served the old version three months later.

The MCP specification already tells clients what to do about this:

For trust & safety and security, clients MUST consider tool annotations to be untrusted unless they come from trusted servers.

So where should the decision about what an agent may do live? Not in the tool's description of itself. Here's what it looks like to put it somewhere you control instead, with a real run you can reproduce in about five minutes.

The setup

The DVARA MCP quickstart starts a gateway, its console and a small Spring AI MCP server with three tools:

Tool	What it does
`get_order_status`	Reads an order's status
`lookup_customer`	Returns a customer record, including an email, phone and card number
`delete_customer`	Deletes a customer record. Irreversible.

Your agent talks to the gateway, not to the server. The gateway lists the server's tools to the agent as demo-tools__<tool> and applies the workspace's rules to every call.

git clone --depth 1 https://github.com/dvarahq/dvara-examples.git
cd dvara-examples/docker-compose/mcp-quickstart
./start.sh

You need Docker and JBang. No licence key and no AI provider account.

The rule

The quickstart loads one policy into the workspace. This is all of it:

version: "1"
rules:
  - id: deny-delete
    conditions:
      mcp_tool:
        denylist: [delete_customer]
    action: DENY
    deny_message: "delete_customer is irreversible and not allowed in this workspace"

Notice what it doesn't depend on: the tool's annotations. If delete_customer claimed to be read-only, or said nothing at all, the rule would apply just the same.

The call

Ask the gateway to run the tool, the way any MCP client would. Replace <your-api-key> with DEMO_API_KEY from the quickstart's .env:

curl -s http://localhost:8080/mcp \
  -H "Authorization: Bearer <your-api-key>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"demo-tools__delete_customer","arguments":{"customerId":"C-42"}}}'

The gateway refuses it before it reaches the server:

{"jsonrpc":"2.0","id":1,"error":{"code":-32001,"message":"delete_customer is irreversible and not allowed in this workspace","data":{"dvara_code":"MCP_POLICY_DENIED","http_status":403,"trace_id":"3054f7e845e4437ea9ec3fb704fe9a0e"}}}

The demo server writes a line to its log whenever delete_customer actually runs. After this call, there's no such line: the server never received it.

The record

Open the console at http://localhost:8090 and go to MCP → Tool Calls. The refused call is there with status 403, next to the allowed get_order_status and the lookup_customer call whose result had its email, phone and card number redacted.

That record is the other half of the point. When someone asks what an agent did, or tried to do, the answer doesn't depend on each server's logging.

Adapting it to your own tools

Deny by name. Add the tools that should never run unattended to the denylist. Start with the ones whose names say delete, drop, revoke, transfer or send.
Hold for a person instead of denying. Some actions should happen, just not without a human saying yes. DVARA can hold a tool call for approval; the native MCP endpoint docs cover how.
Treat a missing hint as unknown. If a tool you haven't classified shows up, the safe default is to ask, not to assume it only reads.
Pin your servers. Catalogues can serve an older version than upstream. Know which version you run.

Annotations are still worth setting if you write MCP servers: they help every client that does read them. Just don't make them the thing that stands between an agent and an irreversible action.

Data in this post comes from our report on MCP tool annotations, which has the full method. Tool data: Glama (glama.ai); Docker MCP Catalog data is MIT-licensed.

Routing Is Not Failover: A Practical Multi-Provider LLM Pattern

DVARA — Mon, 28 Sep 2026 13:08:30 +0000

Adding a second LLM provider does not automatically make an application resilient.

The common mistake is treating provider routing, retry and failover as one decision. They answer different questions at different points in a request. When those boundaries are unclear, teams can send traffic to an incompatible provider, bypass controls or struggle to explain why a request went where it did.

A safer multi-provider design keeps the stages explicit:

Application
  → governance checks
  → capability filter
  → routing strategy
  → selected provider

After an eligible failure:
  selected provider
  → retry same provider
  → compatible failover

Govern first, then route

Provider selection should not happen before policy enforcement. The request should first be associated with its workspace and credentials, then pass through the required policy, PII, guardrail and rate-limit checks.

Capability filtering comes next. A provider may be healthy but still unable to satisfy a request involving structured output, tool calling, vision or another required feature. Filtering before routing ensures that the strategy operates only on eligible providers.

Only then should the gateway select an upstream.

Start with a strategy you can verify

Static weighted routing is useful when two compatible providers should receive a controlled traffic split. In DVARA Open Source 1.8.0, a route can be expressed in gateway.yaml:

providers:
  - type: openai
    api_key: ${OPENAI_API_KEY}
  - type: azure-openai
    api_key: ${AZURE_OPENAI_API_KEY}
    base_url: ${AZURE_OPENAI_BASE_URL}

routes:
  - id: weighted-gpt
    model: "gpt*"
    strategy: weighted
    providers:
      - provider: openai
        weight: 80
      - provider: azure-openai
        weight: 20

Both providers must accept the model identifier sent by the application. Routing selects a provider; it does not translate one provider's model name into another provider's deployment name.

Open Source reads this file at startup, so a routing change requires a Gateway restart. After restarting, verify the result over a meaningful sample of requests. A few calls are not enough to judge a probabilistic distribution. The response trace and structured access log's provider field show which upstream handled each request.

DVARA Open Source 1.8.0 also supports model-prefix, round-robin and canary routing. Latency-aware, cost-aware, geo-aware and intelligent routing are Enterprise capabilities, not Open Source strategies.

Keep recovery separate

Routing asks: Which eligible provider should receive this request first?

Retry asks: Should the same provider receive another attempt after a retryable failure?

Failover asks: Can a compatible alternative safely take over after eligible retries or provider unavailability?

That last word—compatible—is important. A text request succeeding against a fallback does not prove that structured output, tool calling, streaming or vision will also work. Test each request shape and make failure explicit when no compatible provider remains.

Keeping recovery separate also makes the evidence easier to interpret. A trace should show the original routing decision, the provider that received the request, and whether retry or fallback occurred afterward.

One path, one explanation

The practical goal is not merely to distribute traffic. It is to preserve the same governance and evidence path regardless of which provider is selected.

Start with one model family and one operational goal: an even split, a controlled canary or a static weight. Confirm that policy and capability checks still apply, simulate an unavailable provider, and inspect the resulting trace before expanding the route.

For the complete configuration, verification steps and strategy boundaries, read the practical guide to multi-provider LLM routing.

LLM Policy as Code: Version-Controlled Governance for Model and Agent Access

DVARA — Tue, 07 Jul 2026 09:32:44 +0000

Ask a team "which models is your application allowed to call, and under what conditions?" and the honest answer is usually "let me check the code." The rules — which models are approved, which tools an agent may invoke, what happens when a request is too large or comes from the wrong region — are scattered across if statements in a dozen services. No one can review them in one place, no one can test a change safely, and no one can say what a rule would have done before it ships.

LLM policy as code fixes that the same way infrastructure as code fixed server configuration: move the rules out of application code and into a declarative, version-controlled language that a single control point enforces on every call.

What is LLM policy as code?

LLM policy as code is the practice of expressing your governance rules — who can call which models and tools, under which conditions — in a declarative, version-controlled format, and enforcing them centrally at a gateway on every LLM and agent (MCP) request, instead of hard-coding them in each application.

It's the same idea behind Terraform for infrastructure, Open Policy Agent for authorization, and Kubernetes admission control for clusters: the policy is a reviewable artifact, not tribal knowledge. The difference is the domain — an LLM policy matches on AI-native attributes (model, token budget, requested tools, data-residency region) that a general-purpose API gateway or IAM system can't see.

Why governance in application code fails

Rules embedded in app code have four problems, and they compound:

You can't review them. "What's allowed?" has no single answer — you'd have to read every repo that calls a model.
You can't test them. Changing a rule means a deploy and hoping nothing breaks.
You can't roll them back. A bad rule is another deploy to undo, under pressure, with no record of the previous state.
You can't audit them. There's no trail of who changed which rule, when, or what decision it produced.

Policy as code turns all four from "read the source" into "read the policy" — a diffable, testable, reversible, auditable object.

What an LLM policy looks like

A policy is a small YAML document: a set of rules, each with an id, a priority (lower number wins), a conditions block that matches request attributes, and exactly one action. Here's a model allowlist:

version: "1"
rules:
  - id: only-approved-models
    priority: 10
    conditions:
      model:
        allowlist: [gpt-4o, gpt-4o-mini, claude-sonnet-4-5]
    action: DENY
    deny_message: "Model not on the approved list"

Rules evaluate in priority order. The first matching DENY returns immediately; a softer WARN_AGENT action collects a warning and lets the call continue.

The conditions you can match on are the ones that matter for AI traffic: model (allow/denylist), max_tokens, tools and MCP server/tool/args, data_residency, time_of_day, and budget utilization.

When the simple form isn't enough

For rules that need OR, NOT, or arithmetic across fields, a rule can carry a CEL (Common Expression Language) expression: instead of conditions::

version: "1"
rules:
  - id: gpt4o-outside-eu-or-large-requests
    expression: |
      request.model == "gpt-4o" &&
      (context.region != "EU" || request.message_count >= 50)
    action: DENY
    deny_message: "gpt-4o restricted outside EU or for >= 50 messages"

CEL is the same sandboxed expression language Kubernetes admission policies, Envoy, and Cilium use — deterministic and type-checked at submit time. One expression replaces three rules.

The lifecycle is what makes it safe to change

Writing rules as code is only half the value; the other half is changing them without fear:

Author — the policy starts as a Draft, affecting nothing.
Dry-run — simulate it against a real request and see the exact decision before it touches live traffic.
Shadow — run the candidate in production in parallel, recording what it would have done with divergence stats, while changing nothing.
Promote — activate it; conflict detection surfaces contradictory rules, and it hot-reloads across the fleet.
Version & roll back — every change snapshots a version; revert instantly.

Shadow mode is the part teams underrate — the difference between "we think this rule is safe" and "we watched it run against a week of real traffic."

Global and tenant scope, audited on every call

Policies apply platform-wide and per-tenant; both are evaluated on every request, and the decision — allowed, denied, or warned, and by which rule — is recorded on every LLM and MCP call. That record is what turns "we have policies" into "here's proof of what our policies did."

Where it runs

The rules are enforced at the gateway in front of your model and tool calls — one control point every request already passes through, with full visibility into the AI semantics (model, tokens, tools, region, budget). A denied request never leaves your perimeter.

That's the core of DVARA's approach: Policy-as-Code for LLM and agent traffic as a first-class, version-controlled surface — author it in YAML, dry-run and shadow-test it, promote with conflict detection, roll back in one click. Read the full pillar guide → https://dvarahq.com/policy-as-code-llm