Ownware hides write tools from read-only MCP keys across 49 self-hosted business apps

Forty-nine apps, one endpoint

Ownware, a vendor of small self-hosted business tools, has given its entire catalogue — 49 applications, everything except its own AI client — a Model Context Protocol endpoint at POST /mcp since its 3.0 release. In a post on dev.to, the company walks through the harder question that rollout raised: how far a language model should be allowed to go with live business records such as an invoice register.

The connection contract is deliberately minimal. According to the post, an MCP client needs three things: the URL of the customer's own install, an Authorization header carrying an apk_-prefixed bearer key, and stateless MCP over streamable HTTP. Because Ownware implemented the protocol itself rather than bespoke connectors for particular vendors, the same three fields work in the Claude CLI, the OpenAI Responses API tools array, n8n's MCP Client node, or a plain JSON-RPC 2.0 POST. Clients that do not exist yet should work too.

Read-only enforced by omission

The design decision at the centre of the post is where read-only is enforced. Instead of advertising the full tool catalogue and rejecting writes at the permission layer, a read-only key simply leaves the write tools out of the tools/list response. The model never learns they exist, so there is nothing to be persuaded, jailbroken or tricked into using. If a write tool is invoked anyway, the endpoint refuses the request.

Ownware's reasoning is that a model aware of a tool will eventually reach for it, and withholding the tool is stronger than instructing the model to leave it alone. The post points at a classic confused-deputy case: text planted in an invoice description steering an assistant into marking that invoice as paid.

Two further properties carry most of the security weight. Each key is bound to one user account and inherits that user's role, so it is not a privileged side channel around the app's permissions; records hidden from that user in the browser stay hidden through MCP. And every action a read-write key takes lands in the audit log attributed to the user the key acts as, in the same format as human activity.

Two verbs that no key exposes

Beyond scoping, Ownware excludes two operations from the tool surface entirely, on every key and at every permission level: deleting records and emailing customers. The post describes this as a product decision rather than a technical constraint. Deletion cannot be reviewed after the fact, and a message sent to a client list cannot be recalled. A request to tidy up old invoices is, by design, one the tools cannot fulfil.

Stated limitations

The post is candid about rough edges. Tool catalogues differ per product and live in an API.md shipped inside each download rather than one central schema, which gets clumsy when driving several apps at once. The OpenAI example sets require_approval to "never" because it makes the integration smooth, but Ownware says it would not enable that on a write-capable key. And the read-only boundary defends against the model, not the account holder: anyone who can sign in as the key's user can mint a broader key from the same settings page.

Why it matters

MCP is fast becoming the standard way to hand agents access to real systems, and the common pattern — a scope string in a token plus an implicit hope that the model behaves — depends on model compliance. Ownware moves enforcement to what the endpoint advertises, which matches how agents actually fail: injected prompts can only invoke tools that exist. Binding keys to existing users and logging under their identity also sidesteps two chronic mistakes when bolting APIs onto role-based apps: parallel authorisation systems and unattributable automation.

There is a self-hosting angle too. Because the endpoint is client-agnostic, a small business running several of these tools can query all of them through one interface without data leaving its server, including with a locally hosted model. This is a vendor describing its own design rather than an independent audit, but as a checklist for exposing business software to agents — omit what should not be used, bind keys to users, log under identity, and never expose irreversible or outbound operations — it is concrete and testable.