Per-user keys, hash-stored
One key per human, not one key per app. Hash on write, prefix-display on read, revocable from an admin surface a non-engineer can run.
A typed Model Context Protocol surface over your operational entities — customers, deals, tickets, drafts, whatever your real objects are. Per-user studio keys, audit-logged on every call. Cite-back identifiers. Five patterns the agent reads, your engineers read, and your auditors read. Ships inside an Avira install.
Your team gets a production MCP server tuned to your substrate. Each tool is small, named, and predictable; one is broad and fuzzy. Every entity returned carries a stable, citable identifier. Every call is audit-logged. Per-user keys instead of shared secrets, so you can see which human asked the agent to do what. The patterns below are the spec; the install is where the work gets done.
The server is closed and ships as part of an Avira install. The patterns it embodies are written down here because any team building a production MCP server runs into the same five problems we did, and most of them — including ours, the first time — get halfway.
One key per human, not one key per app. Hash on write, prefix-display on read, revocable from an admin surface a non-engineer can run.
Every tool publishes a JSON Schema for input and output. Agents read the schema; the human reading the agent reads the schema; the eval suite reads the schema. Drift becomes loud.
Every entity returned carries a stable, citable identifier (RECORD:abc, TICKET:1042). The agent cites those back into its output; auditors trace forward to source.
Most tools are small and predictable; one is broad and fuzzy. We push fuzziness into search_* rather than smearing it across every getter. Agents learn the rule fast.
Tool name, key, input hash, latency, success/error, and a foreign key to the conversation that called it. Six months later, “why did the agent answer that way” is a single SQL query.
The patterns above are not theory. They are what hardened in the workspace pattern we built for our own program and run today. The reason this page sits on the Stack rather than tucked inside the Avira page is that the patterns travel: they are not specific to any one substrate. They are specific to running an MCP server that survives a Wednesday.
Inside an Avira install today: the server itself, the per-user studio key surface, the cite-back identifier convention, the typed-tool schema discipline, and the audit log against your database. The toolchain around the server is deliberately not in scope yet:
We will build any of these into the product when an install needs them. If you are evaluating MCP Dev and one of the above is a hard requirement, write to us and we will tell you honestly whether to wait.
The server is one of the five artefacts in an Avira install. Same engagement model: a small team, four to six weeks, one organisation at a time. The MCP server is the typed-access spine that the rest of the kit — the skill library, the folder convention, the citation standard, the governance bar — sits on top of.
Tell us the substrate — what your real entities are, who calls the tools, what regulated reader has to be able to trace the output back. One paragraph is enough.