Server data from the Official MCP Registry
Turn an IDF domain into an MCP server with invariants and role scopes in every tool description.
Turn an IDF domain into an MCP server with invariants and role scopes in every tool description.
This MCP server adapter exhibits solid security practices with proper authentication via JWT tokens, secure credential handling through environment variables, and well-designed separation of concerns between the MCP layer and a backend runtime. The codebase is clean and focused, with comprehensive input validation and no evidence of malicious patterns. Minor code quality observations around error handling and logging do not materially impact security posture. Permissions align appropriately with the server's purpose as a domain-semantics bridge for AI agents. Supply chain analysis found 1 known vulnerability in dependencies (1 critical, 0 high severity). Package verification found 1 issue.
7 files analyzed · 7 issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
This plugin requests these system permissions. Most are normal for its category.
Set these up before or after installing:
Environment variable: IDF_SERVER
Environment variable: IDF_DOMAIN
Environment variable: IDF_BOOTSTRAP
Environment variable: IDF_ONTOLOGY_PATH
Environment variable: IDF_AUTH_TOKEN
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-intent-driven-software-idf-mcp": {
"env": {
"IDF_DOMAIN": "your-idf-domain-here",
"IDF_SERVER": "your-idf-server-here",
"IDF_BOOTSTRAP": "your-idf-bootstrap-here",
"IDF_AUTH_TOKEN": "your-idf-auth-token-here",
"IDF_ONTOLOGY_PATH": "your-idf-ontology-path-here"
},
"args": [
"-y",
"@intent-driven/mcp-server"
],
"command": "npx"
}
}
}From the project's GitHub README.
Stop giving AI agents API keys. Give them a domain.
@intent-driven/mcp-server exposes any IDF domain
to Claude Desktop / Cursor / Zed as a Model Context Protocol server — with
domain semantics in tool descriptions (preconditions, invariants,
irreversibility, role scopes) and structured rejections when the agent
tries something it shouldn't. Not a 500. Not a string. A JSON shape the
LLM can read and adapt to.
→ Landing & demo: fold.intent-design.tech → 5-min quickstart: github.com/intent-driven-software/fold-runtime-quickstart
On April 25 2026 a Cursor agent powered by Claude Opus 4.6, working on a credential mismatch in PocketOS staging, found an unrelated API token, decided to delete a Railway volume to fix things, and wiped the production database and all volume-level backups in 9 seconds. The agent's own post-mortem:
"I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify. I didn't check if the volume ID was shared across environments."
30-hour outage. PocketOS rolled back to a 3-month-old backup. (The Register · FastCompany · OECD AI Incident #6153)
This isn't an alignment problem. The system never told the agent what was allowed, why it shouldn't, or what would happen if it tried. Existing MCP servers don't either — tool descriptions carry endpoint shape and not much else. The agent learns by colliding with 500s.
This package fixes that. The MCP tool descriptions carry the why the call might fail; the rejection carries the what failed, structured.
@intent-driven/mcp-server is a stdio MCP adapter that talks to a
Fold runtime over an HTTP API. The runtime is a sibling service —
not middleware in your existing app, not codegen at runtime. Your current
backend stays where it is; the IDF artifact describes the agent-facing
surface, and the runtime serves it on its own port (default :3001).
┌──────────────────┐ stdio ┌──────────────────┐ HTTP ┌────────────────────┐
│ Claude Desktop │ ◀─────────▶│ @intent-driven/ │ ◀───────▶│ Fold runtime │
│ Cursor / Zed │ │ mcp-server │ │ (idf host :3001) │
└──────────────────┘ └──────────────────┘ └────────┬───────────┘
│ reads
▼
┌────────────────────┐
│ IDF artifact │
│ (entities + intents│
│ + invariants + │
│ roles + __irr) │
└────────────────────┘
The MCP server is what Claude/Cursor connects to. The runtime is what enforces the rejection. The IDF artifact is what you author.
Who this is for. You're the engineer at a 5–30-person team putting an AI agent into production this quarter — on top of a real backend, with real customers, real SOC2 review on the horizon. You don't want a guardrail layer that reviews after the fact. You want the system itself to refuse the wrong action — before the call, with a structured reason the agent can read.
submit_response in the freelance domain:
Executor публикует Response на Task в status=published; Response.status=pending; +1 в Task.responsesCount
Creates: Response(pending)
Preconditions: task.status = "published"
May fail on (domain invariants):
- Response.taskId must reference existing Task.id
- Response: max 1 per taskId where (status="selected")
- Response: row count rule per taskId where (status="pending") [info]
release_payment in the same domain:
Customer releases escrow to executor. After confirmation, money is gone — forward-correction only.
⚠️ Irreversible action (point-of-no-return: high). Forward-correction only after this effect is confirmed.
May fail on (domain invariants):
- Deal.status transitions allowed: in_progress→completed, on_review→completed, ...
None of this is hand-written for the MCP server. It's all derived from one declarative IDF artifact (entities + intents + invariants + roles
Agent submits a $50,000 BTC long without preapproval. The runtime intercepts before any effect lands in storage:
HTTP 403
{
"error": "preapproval_denied",
"intentId": "agent_execute_preapproved_order",
"reason": "no_preapproval",
"details": {
"entity": "AgentPreapproval",
"ownerField": "userId",
"viewerId": "user_5f57c252"
}
}
The next move for any sane agent: stop, ask the human for a preapproval, retry. Not a 500. Not a string. A JSON shape the LLM can read and adapt to.
The fastest path is the fold-runtime-quickstart — two commands, Docker-bundled, no path configuration:
git clone https://github.com/intent-driven-software/fold-runtime-quickstart && cd $_
docker compose up # ~3 min first time, ~5 sec after
# in another terminal
npm install
npm run demo:rogue && \ # Act 1: $50K trade → 403 with structured rejection
npm run demo:grant && \ # Act 2: investor issues $1K cap (one declarative effect)
npm run demo:smart # Act 3: agent reads cap, scales to $950, executes 200 OK
If you'd rather drive the host yourself (e.g. for development against your own ontologies), see the next section.
You need a running IDF host on localhost:3001 (the quickstart's
docker-compose gives you that, or run idf
manually) and a bootstrapped domain.
# bootstrap from local FS (ontology + intents)
mcp-idf --domain=invest --ontology-path=/abs/path/to/idf/src/domains/invest
# skip bootstrap (domain already loaded by another client / docker)
mcp-idf --domain=invest --no-bootstrap
Flags / env vars:
| Flag | Env var | Default |
|---|---|---|
--domain | IDF_DOMAIN | booking |
--server | IDF_SERVER | http://localhost:3001 |
--ontology-path | IDF_ONTOLOGY_PATH | ./src/domains/<domain> |
--agent-email | IDF_AGENT_EMAIL | mcp-agent@local |
--no-bootstrap | IDF_BOOTSTRAP=0 | bootstrap on (load FS ontology) |
~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"invest": {
"command": "npx",
"args": ["-y", "@intent-driven/mcp-server"],
"env": {
"IDF_SERVER": "http://localhost:3001",
"IDF_DOMAIN": "invest",
"IDF_BOOTSTRAP": "0",
"IDF_AGENT_EMAIL": "claude@local"
}
}
}
}
IDF_BOOTSTRAP=0 if the host already has the domain loaded (the quickstart
container does this on docker compose up). Restart Claude Desktop fully
(⌘Q + relaunch — closing the window isn't enough). All
agent-callable intents appear in the Tools menu.
IDF intent.canExecute ─→ MCP tool
intent.parameters ─→ JSON Schema inputSchema
intent.conditions ─→ description hint for LLM
ontology.invariants (relevant) ─→ description block "May fail on"
intent.irreversibility:high ─→ annotations.destructiveHint + warning
role.visibleFields ─→ resource per collection
preapproval guard ─→ automatic scope/limits
checkOwnership ─→ automatic access control
One tool per intent in ontology.roles.agent.canExecute.
name — intentIdtitle — intent.namedescription — intent.description + Creates: … + preconditions +
May fail on (domain invariants) block + irreversibility warning when
irreversibility: "high"inputSchema — JSON Schema from particles.parameters:
entityRef / id / text / textarea / select → stringnumber → numberboolean → booleandatetime → string + format: "date-time"email → string + format: "email"annotations.destructiveHint — true when
intent.irreversibility === "high" (§23 IDF: effect-level point of no return)One resource per collection in role.visibleFields[entity]. URI scheme:
idf://<domain>/<collection>.
resources/read returns the filtered world from
/api/agent/:domain/world — already scoped per viewer (single-owner
role.scope).The MCP community solves these by hand in every server:
role.visibleFields.roles.agent.canExecute.preapproval.requiredFor with maxAmount / dailySum.effect.context.__irr.point === "high" → destructiveHint: true automatic.intent.conditions land in tool description as Preconditions:.May fail on (domain invariants). Closes the #1 complaint about hand-rolled MCP servers: "the server doesn't carry domain semantics — the LLM knows what to call but not why it'll fail."Three reference points from the public IDF host runtime:
| Domain | Shape | Time |
|---|---|---|
invest | 14 entities · 61 intents · 5 invariants · ~600 lines | a weekend, hand-written |
gravitino | 253 entities (Apache catalog OpenAPI) · 120 intents | imported in <1h, enriched in 2 days |
workflow | 9 entities · 47 intents · timer queue · cascade rules | a day |
Where the speed comes from (all in @intent-driven/cli):
idf import postgres — reads your live schema, generates entity
baseline with FKs and column types as fieldRole.idf import openapi — reads your existing API spec, generates intents
idf import prisma — same story for ORM-driven backends.idf enrich — LLM pass to fill label, fieldRole, compositions,
suggested roles.agent.preapproval predicates from your existing
code comments.The author-once-then-forget loop is the whole point. Once the artifact exists, you don't regenerate scaffolding on schema change — the runtime re-reads and serves four readers (UI, voice, agent, document) off the same file.
The protocol is reliable, but it needs the IDF domain to be authored
correctly. Without these, tools/list may return empty,
tools/call may return domain_not_supported, resources may be empty:
ontology.roles.agent must be declared. No agent role → no tools, no resources.role.agent.canExecute — list of safe intents. Avoid __irr:high without preapproval.role.agent.visibleFields — array of fields or "own" / "all" / "aggregated" markers.server/schema/effectBuildersRegistry.cjs in idf) must include your domain. Without it tools/call returns domain_not_supported.ownerField. When an entity has ownerField, the SDK filterWorldForRole filters out rows where row[ownerField] !== viewer.id. For public catalogs (e.g. Task with status: "published") use role.scope with a via-collection or a separate agent-roleable projection (roadmap).tools and resources only. prompts / completion — roadmap.POST /exec). Long-running via MCP tasks API — next.MIT
Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
by mcp-marketplace · Developer Tools
Create, build, and publish Python MCP servers to PyPI — conversationally.