Before You Connect the Tool

Adding an MCP server is a trust grant. mcpforge builds the capability; MCPAudit verifies the blast radius before an agent can touch it.

Adding an MCP server to an AI agent's config is a trust grant, and almost nobody treats it like one. You npx a package someone published, point your agent at it, and now a process you didn't write has a standing invitation to your files, your network, and your shell, often launched from a remote package that can change underneath you between runs. The convenience is real. The blast radius is invisible. I built two small tools to make both halves explicit, and they turned out to be one loop.

Forge: a sentence in, a tested server out

mcpforge (on PyPI as fastmcp-builder, and still alpha) takes a plain-English description ("a weather server that returns today's forecast for a city") and scaffolds a complete project: a working FastMCP server with typed input validation and error handling, a real pytest suite, project metadata, a README, and a client config ready to install. The detail I care about is that the tests are generated in the same pass as the server, not retrofitted, and a validation step runs syntax checks, a security scan, linting, import checks, and the test suite before you ever run the thing. The point isn't to replace writing servers by hand. It's to make owning a server cheap enough that you reach for that instead of installing a stranger's.

Audit: what can this thing actually touch?

MCPAudit (on PyPI as mcp-audits) points at your configured MCP servers and answers the question the install flow never asks: what can each one reach? It classifies every server's capability across six categories (file read, file write, network, shell execution, destructive operations, and exfiltration) and scores the surface 0 to 10. The useful trick is its --skip-connect mode, which does the whole pass from config alone: no servers spawned, no network touched, risk inferred from declared commands, transports, credential key names, and remote URLs. That's the version you can safely run on someone else's machine or paste into a report.

It reads; it never edits a config, and it reports credential key names, never values. Output comes as a terminal table, JSON, a self-contained HTML report, or SARIF for a CI security pipeline, and a policy file can fail a build when a server crosses a line you set. The detector I find most useful is the one for the lethal trifecta: a single server that can read files and ingest untrusted content and exfiltrate, the exact combination that turns a helpful tool into a data-exfiltration path, and the exact thing no per-tool glance ever catches, because the danger is in the assembly.

Why they're one note and not two

Because they're one loop, and the loop is the point. Forge a server with validated, tested code; then audit its permission surface before you grant an agent access. They even share a no-API-key demo that runs the whole thing end to end (scaffold a server, validate it, then config-scan it) so you can watch the trust grant get made legible without spending a token.

Put that way, it's the same bet the rest of this site keeps making, aimed at the MCP ecosystem: trust you can't see is just a vibe. Build the capability with the checks baked in, then enumerate exactly what you handed it, then decide. The default workflow today skips the middle step entirely: install, grant, hope. These two tools are an argument that the middle step should be cheap and routine, not heroic.

Honest about where they are

I'd rather undersell these than oversell them. mcpforge is alpha; it wires the call structure of a server reliably, but the real data logic, production auth, and rate-limiting are still yours to write: it builds the skeleton, not the muscle. MCPAudit I treat as pre-beta despite a confident package classifier; its prompt-injection detection is pattern-based, so a novel phrasing can slip it, and a config-only scan reasons about declared capability, not runtime behavior. And neither tool verifies that a generated server's actual powers match its description; the forge and the audit are deliberately separate steps. You build, and then you check, because the thing that built it doesn't get to vouch for it.