MCP Server Generator
Generate MCP tools from the CLI the team already trusts.
Beltline exports MCP tools from the same command definitions that power the CLI, so humans and agents share auth, inputs, outputs, and safety rules.
Do not build a second tool layer for agents. The CLI is the human interface. MCP is the agent interface. Beltline keeps them aligned.
Agents need tools. The team needs guardrails.
Agent integrations fail when they are built as one-off wrappers with vague names, weak schemas, missing auth, and no confirmation rules. When the MCP server is a separate project from the CLI, the two drift apart. Command names diverge. Auth handling differs. Safety rules get skipped.
Beltline keeps the command, schema, auth context, and safety metadata together in one manifest.
Before and after Beltline
| Before | After Beltline | |--------|----------------| | Separate MCP server project | MCP generated from the CLI manifest | | Duplicated API logic per surface | Shared handlers between CLI and MCP | | Unclear tool descriptions | Structured schemas from the manifest | | Weak or missing safety rules | Per-command confirmation metadata | | CLI and MCP drift apart over time | One source of truth |
Export an MCP server from an existing CLI
beltline mcp export
acme mcp serve
Agent prompt:
Check failed production deployments from the last hour.
Draft a rollback plan.
Ask before running any rollback.
Generated MCP tools:
deployments_list
deployments_get
deployments_rollback requires_confirmation: true
incidents_open
The rollback tool carries confirmation metadata. An agent cannot run it blindly — it must surface the resolved arguments for human approval first.
What Beltline handles for you
One command definition, two consumers
The same manifest block that generates acme deployments rollback also generates the deployments_rollback MCP tool. Change one, both update.
Structured inputs agents can understand Tool schemas are derived from the same argument definitions the CLI uses. Agents get typed, named parameters — not a string to parse.
Confirmation rules for writes
Set confirmation: always or confirmation: write in the manifest. Beltline carries that metadata into the MCP tool so clients can enforce human-in-the-loop approval before destructive actions.
Machine-readable errors Structured error output makes agent error handling reliable. No scraping terminal prose to figure out what went wrong.
Stdio locally, HTTP when remote access is needed
acme mcp serve exposes a stdio transport for Claude Desktop and Cursor. Beltline also exports a Streamable HTTP server when remote agents need access.
Frequently asked questions
Do I need an existing CLI? No. The CLI and MCP server can be generated together from the Beltline manifest. Start with the manifest and produce both surfaces at once.
Can I block dangerous commands from agents?
Yes. Exclude commands from the MCP export entirely, or mark them with confirmation: always so agents cannot call them without human approval.
Can agents use the same auth? Yes. Auth requirements are part of the shared command definition. The same OIDC session that powers the CLI also covers MCP calls.
Does this follow the MCP spec? Yes. Beltline targets the current MCP spec with OAuth 2.1, Resource Indicators (RFC 8707), and PKCE for HTTP transport.