Forgeprint MCP server

Forgeprint

Others say "here are 200 skills, go find yours." Forgeprint says "tell me who you are and what you're building — here is your package."

Forgeprint is a community-grown blueprint catalog and MCP server that lets a coding agent bootstrap a new project with the right context in one shot: the AGENTS.md, the skills, the MCP and plugin configuration, and a deterministic setup recipe the agent can execute.

Status: pre-release. Four blueprints, working tooling, and an MCP server

with all six tools, published and connectable today:

bash

claude mcp add forgeprint -- npx -y forgeprint-mcp

On Windows PowerShell, quote the separator:

claude mcp add forgeprint "--" npx -y forgeprint-mcp.

The catalog is browsable at .

Roadmap has the rest.

The problem

Every new project starts cold. You hunt down the requirements, write the rule file by hand, wire up the MCP servers, pick the plugins, and get the setup steps wrong twice before they work. Hours of it — repeated by everyone, on every project, forever.

That knowledge is not hard to write down. It is just never written down in a form another agent can use.

What makes it different

1. A resolver, not a catalog to browse

You do not search Forgeprint. You describe yourself and your goal, and it returns exactly one blueprint.

You:   I know C#. I want to build a multi-tenant SaaS API.
Agent: [resolve] → Forgeprint returns questions: which database, which auth,
       self-hosted or cloud?
You:   Postgres, JWT, cloud.
Agent: [resolve] → one blueprint, why it was chosen, what is missing on this
       machine, and the setup plan.

When the profile is incomplete, the resolver does not guess: it returns the questions your agent should ask you. When two candidates are genuinely close, it returns both as a question and lets you pick — never as a list to sift through. When nothing fits, it says so, names the closest blueprint, explains why it does not fit, and offers to file a request. It never invents a match.

Scoring is weighted: a language you already know beats everything else.

2. A setup recipe, not a description

setup.md is a script, not prose. Every step is numbered, is a single command or a single file operation, and ends with a verification command. Versions are pinned. Option branches are explicit. The agent executes it; Forgeprint itself installs nothing and runs nothing on your machine.

3. A quality gate, not a junk drawer

Every pull request passes schema validation, a setup test that actually runs the recipe in a clean container, and a duplicate report against the closest existing blueprint. Two blueprints may not claim the same stack, project type and requirements — a better one replaces the old one instead of sitting next to it.

There is no inheritance and there are no variants. Variation is expressed as options, capped at three fields with three values each, so the whole matrix stays testable. See ADR 0001.

4. Standards-compatible, not another format

Forgeprint follows the existing specs — AGENTS.md, SKILL.md, marketplace.json — so its output drops into the tools you already use, and skills remain installable through the usual channels:

npx skills add forgeprint/forgeprint            # skills.sh CLI
gh skill install forgeprint/forgeprint blueprint-author

Both are verified against the real tools before each release, and forgeprint validate fails on a skill that would not install — see ADR 0006.

How it compares

Forgeprint is not trying to replace most of these. It sits in the gap between them.

Shortened. The full README is on GitHub.