@skeletiq/mcp
Design in SkeletIQ, build with your coding agent.
SkeletIQ turns a prompt into a critiqued system architecture — components, data stores,
connections, decisions, open questions — that you refine on a canvas and then release. This MCP
server hands that release to any MCP-capable coding agent: it orients from a brief written into
your repository's AGENTS.md, builds in a deterministic order, and reports back what it built.
Install
Nothing to install — the server runs via npx.
You need a personal API token: in SkeletIQ, go to Settings → Agent access, create one, and copy it (it is shown once).
Claude Code
claude mcp add skeletiq \
--env SKELETIQ_API_KEY=skq_your_token_here \
-- npx -y @skeletiq/mcp
opencode
{
"mcp": {
"skeletiq": {
"type": "local",
"command": ["npx", "-y", "@skeletiq/mcp"],
"environment": { "SKELETIQ_API_KEY": "{env:SKELETIQ_API_KEY}" },
"timeout": 600000
}
}
}
The timeout matters. A generation runs for around 217 seconds typically and up to 450 at the
limit; opencode's default is far below that, and it will kill a perfectly healthy run.
Any other host
Run npx -y @skeletiq/mcp over stdio with SKELETIQ_API_KEY in the environment.
Configuration
Scopes
A token grants only what you tick. The server's tools need:
read alone is a good starting point: the agent can orient and build, but cannot spend anything.
Two things the table above cannot say in a cell:
reporton its own does nothing.check_driftandrequest_decision_changelook the project and the version up before they can report against them, and those lookups areread. Areport-only token is refused.generatewithoutreadstill generates, but the answer is thinner: the tool reads back the design it just created to describe it, and reports that failure as a thinner answer rather than a failed generation — telling an agent the generation failed would invite it to pay for the whole thing again.
Everything else is out of reach by construction — a token cannot mint another token, read or change your provider keys, see billing, or delete your account, whatever scopes it carries.
Tools
How a session goes
list_projects→ resolve the project a person named.get_design(mode: "brief")→ write the fenced block intoAGENTS.md.get_design(mode: "readiness")→ see what is still undecided, and ask.get_design(mode: "build_order")→ build in that order.get_design(mode: "component", component_id: …)→ read each piece as you reach it.check_drift(covers: [...])→ report progress.
Four things to know
The brief is a managed block. It goes inside a skeletiq:brief HTML-comment fence in your
AGENTS.md. A refresh replaces the whole block. Never append a second, and never edit inside one:
your edits will disappear on the next refresh, silently.
A draft is not a release. An unreleased version changes on every canvas save, with nothing to tell your repository it moved. The tools label drafts, and tell you when a newer release exists.
Component ids belong to one version. A regeneration mints new ones. When check_drift returns
unknown ids with suggestions, they are suggestions — put them to a person rather than assuming the
mapping.
critique_architecture's optional inputs are not neutral. Omitting one does not skip a
question; it answers it. With no domain, no compliance framework applies (secondary_domains
select none — they add that domain's design checks as advice — so name a framework when it must
apply), so no compliance finding is possible and the score comes back higher than the SkeletIQ app shows
for the same design — by up to 15 points. With no exposure, the design is assessed as
internet-facing, which is how an air-gapped system gets told to add a CDN and a WAF. The response
says what was actually used — frameworks_checked and exposure_assessed — and the text output
warns when a default was applied. Read those before reporting a score to a person.
Which model runs a generation
Whichever one the account holder chose under Settings → Agent access. The tools take no runtime argument, deliberately: the model asking for a design does not get to choose what it costs you.
Development
This repository is the source of the published @skeletiq/mcp package. The connector is developed
in SkeletIQ's monorepo, alongside the API it talks to, and mirrored here — so the history you see is
the package's real history, not a squashed snapshot. A pull request opened here cannot be merged,
because the next sync would overwrite it; CONTRIBUTING.md explains what to do
instead.
Node 20 or newer.
npm install
npm test # vitest — hermetic: no network, no services, nothing to seed
npm run build # tsup, to dist/index.js
npm run typecheck
npm run lint
The tests mock the SkeletIQ API rather than calling it, so a clean clone runs them without a token and without an account.
If npm install fails with Cannot read properties of null (reading 'edgesOut'), you are on npm
10.9.x — the version Node 22 ships — which cannot resolve this tree; vitest@4 alone triggers it.
npm install -g npm@11 fixes it. This affects cloning and building only: installing the published
package with npx works on that npm.
Licence
MIT — see LICENSE. Source: Sabhahith-Works/skeletiq-mcp — issues and questions go there.
The SkeletIQ platform is AGPL-3.0-or-later; this connector is MIT so it can be embedded, vendored and forked freely.
"SkeletIQ" is a mark of Sabhahith Works Private Limited — see NOTICE. Security reports go to [email protected], not to the issue tracker: SECURITY.md.