mcp-beaver
docs
Write the guardfile. Everything else derives.
mcp-beaver renders a umbra guardfile into a guarded MCP server. Each grant becomes one MCP tool and one matching HTTP endpoint, with the input schema derived rather than written, so an operation nobody declared has neither. One runtime image serves every guardfile, and a generic Helm chart carries it to a cluster.
If you are still deciding whether any of that is your problem, the case for mcp-beaver is the better place to start. These pages assume you already decided.
Synced from mcp-beaver eebbe24, 2026-08-27. A copy, so the repository is the source of truth if the two disagree.
Getting started
Guides
- serve Every grant becomes one tool and one endpoint.
- lint Validate a spec offline, then print its tool names.
- The passthrough proxy Wrap an existing MCP down to an exact allowlist.
- Argument pins Fix a proxied argument when the scope rides in it.
- serve-ssm One parameter, bounded twice, in policy and in IAM.
- serve-s3 The one write-capable mode, fixed to a bucket.
- Image and packaging One distroless binary drives every guardfile.
- CI Gate on every push, publish on a landed commit.
- The Helm chart Adding an MCP becomes a values file and an upgrade.
- Sidecars and upgrades Co-locate an upstream, and why a selector blocks an upgrade.
Reference
- Context nodes Instructions, resources, prompts, server-info.
- Controls Pins, rate limits, cache, withheld verbs, confirmations.
- Extraction Turn a PDF or a feed into something a model can read.
- Chart values Every value the chart takes, and what it defaults to.
- Request bounds Deadlines, cancellation, and the upstream client.
- Protocol conformance What MCP 2026-07-28 requires, and what it deprecated.
- Telemetry Opt-in OpenTelemetry, a no-op until you configure it.
- Structured logs One JSON line per call, joined to its trace.
Concepts