MCP servers for internal systems

The mcp package does client and server, and the capability model is exactly what you want when exposing internal tools to an agent.

The problem

Agents need safe access to ticketing, runbooks, and deployment APIs. MCP is the wire format; the hard part is guaranteeing a tool handler cannot read arbitrary files or call arbitrary URLs when an agent prompts it to.

Why Ecko

mcp package both ways: Implement a server that exposes vetted tools, or call someone else's MCP server from Ecko orchestration code - same language, same grant model.
Grants per dependency: Each package the server imports gets only what ecko.json grants it: the Jira client gets "grant": ["net"], the prompt formatter gets nothing. The grants are one file a reviewer can read.
One binary deployment: Ship the server as a single executable in your internal platform. No Node version manager on the host.

In practice

mcp-server.ecko

import mcp

RUNBOOKS = { deploy: "Tag, wait for CI, then promote.", rollback: "Promote the last good tag." }

# The agent gets this one tool and nothing else: no shell, no file reads.
runbook = mcp.tool(
    "runbook",
    "Look up a runbook by name",
    { type: "object", properties: { name: { type: "string" } }, required: ["name"] },
    fn(args) get(RUNBOOKS, args.name) ?? "no runbook called {args.name}",
)

mcp.serve_stdio([runbook], { name: "ops", version: "1.0" })

Related cases

Internal admin CLIs The cli package for flags and subcommands, one binary to scp, and mock mode for dry-run paths that still execute real validation logic.

All 9 use cases →

Try it on your workload.

Install Ecko Open the playground