Trentina MCP server

Trentina

<!-- mcp-name: io.github.crunchtools/trentina -->

Trentina is a secure MCP gateway that inspects everything between your AI agents and the outside world — web content, MCP tool responses and tool definitions, Matrix messages, LLM completions, and monitoring alerts — through a three-layer defense pipeline at every ingress, with per-profile enforcement (flag or block) and a full audit trail. Content is never silently modified: what your agent reads is what actually arrived, plus Trentina's verdict. (E2EE Matrix rooms are ciphertext at the gateway and outside what any proxy can defend.) Named after the 1377 quarantine system from Ragusa, where incoming ships had to anchor offshore for thirty days before anyone was allowed into the city. Same idea: keep the commerce flowing without letting something dangerous through.

Capabilities

MCP Gateway

Single chokepoint between your agents and all their MCP backends. One endpoint, one bearer token, one audit log — instead of each agent connecting directly to dozens of MCP servers. Backend tools are namespaced automatically (slackslacksearchmessages, githublistissuestool) so there are no collisions.

Authentication

Four ways a client can prove who it is, chosen per profile: a static bearer token, an OAuth identity Trentina issues while proxying login to Google (with dynamic client registration or a provisioned confidential client), or a token minted by an external identity provider that Trentina only verifies — for connectors that will not authenticate against a third-party authorization server.

Per-Agent Profiles

Each consumer — Claude Code, Hermes, OpenClaw, or any MCP client — gets its own profile with independent tool access, defense settings, and authentication. Your human-supervised agent can have full tool access while your autonomous agent gets a locked-down subset, all through the same gateway.

Operator Profile

Trentina is built to be run by an agent. One profile, role: operator, is the Operator agent's seat. It installs and configures the gateway, reloads it, and administers it through Trentina's own admin tools. It is also the gateway's service identity: compression and perimeter judgement of shared tool descriptions run on the operator's model and bill the operator's key. They never run on whichever tenant happens to sort first.

Tool Allowlists & Denylists

Control which tools each agent can even see. Tools not in the allowlist are stripped from tools/list responses before they reach the consumer — they never enter the agent's context window. Supports exact names and glob patterns (delete, gmail_*). Reduces both context cost and attack surface.

Parameter Guards

Per-tool argument validation at the gateway level. Restrict what values an agent can pass, not just which tools it can call. Example: "this agent can send email, but only to user@example.com." The call is rejected before it reaches the backend — no tokens spent, no side effects. Deterministic enforcement that doesn't depend on LLM behavior.

Response Guards

The egress half of parameter guards: the same allow/deny constraint applied to what a backend returns, before the result is reduced, scanned or relayed. Argument-side matching cannot cover a semantic tool — an agent asking a memory server for "my employer's roadmap" sends nothing matchable, and the restricted material arrives in the response. Deny-oriented, blocks the whole response rather than scrubbing it, and audited as policy rather than failure.

Three-Layer Defense Pipeline

Shortened. The full README is on GitHub.