Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
33 tools that make AI write, implement, and verify intent against explicit, testable constraints.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
Authorization标为机密的值是你账户的钥匙。千万不要分享给别人,也不要粘贴到聊天里。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
这个地址需要在请求的 header 中放入密钥,而添加连接器的菜单无法设置。请改用 Claude Code、Cursor 或 VS Code。
在终端中运行这条命令
claude mcp add --transport http ivd https://mcp.ivdframework.dev/mcp --header 'Authorization: Bearer {api_key}'运行前请先填写空着的值。
粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"ivd": {
"url": "https://mcp.ivdframework.dev/mcp",
"headers": {
"Authorization": "Bearer {api_key}"
}
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"ivd": {
"type": "http",
"url": "https://mcp.ivdframework.dev/mcp",
"headers": {
"Authorization": "Bearer {api_key}"
}
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个地址需要在请求的 header 中放入密钥,而添加连接器的菜单无法设置。请改用 Claude Code、Cursor 或 VS Code。
你的选择通过 Cookie 保存在这台设备上,无需账户。
Authorization 机密 必填 HTTP header这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
我们还没有读取这个服务器的工具列表;我们会轮流检查各个端点。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过 GitHub 账户 leocelis 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
尚未检查;我们会轮流检查各个端点
尚未检查;我们会轮流检查各个端点
尚未检查;我们会在检查端点时读取工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
你需要填写:Authorization
它在作者的云端运行。通过互联网连接,无需安装,但你发送的内容会经过作者的服务器。
GitHub 仓库最后更新于–,最新版本(3.1.2)于4个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,所以接受远程 MCP 服务器的应用也可以使用,例如开启开发者模式的 ChatGPT。
同一分类中有:Spec Driven Development, Remote Desktop Commander, EmbeddedCI BenchPod
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Drive a BenchPod hardware-in-the-loop bench: power, flash, UART, I2C, CAN, analog and logic.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
Intent-Verified Development (IVD)
A framework where AI writes the intent, implements against it, and verifies — so hallucinations are caught and turns drop to one.
→ ivdframework.dev — full docs, hosted server, and access request
New here? Start with judgment_explained.md — a 5-minute, plain-English on-ramp that explains what problem the Judgment phase solves and how, before you read the spec.
AI agents hallucinate not because they're bad — but because you're feeding the wrong knowledge system.
Research shows LLMs rely primarily on contextual knowledge (the prompt) over parametric knowledge (training data) — but only when the context is structured and precise (Huang et al., ICLR 2024; 9-LLM contextual vs. parametric study, 2024). When you give vague prose — a PRD, a user story, a chat message — the context channel is underloaded. The model fills the gaps from training. Those gaps are the hallucinations.
Without IVD With IVD
You: "Add CSV export" You: "Add CSV export for compliance" AI: [builds with wrong columns] AI: [writes intent.yaml with constraints] You: "No, these columns, ISO dates" You: "Yes, that's what I meant" AI: [rewrites, still wrong] AI: [implements, verifies against constraints] You: "Still not right..." You: "Done. First try." Many turns. Many hallucinations. One turn. Mismatches caught by the constraint check, not by you.
IVD saturates the contextual channel with structured, verifiable intent — so the model has nothing to guess.
Works locally. No API key required. Under 5 minutes.
git clone https://github.com/leocelis/ivd.git && cd ivd
python3 examples/intent_demo/run_demo.py
Runs offline. Shows a vague prompt producing a hallucinated implementation, then the same request run against a structured intent artifact — with the constraint check catching the mismatch before you'd ever see it. This is the core loop this README is about; everything below is how to wire it into your own agent.
git clone https://github.com/leocelis/ivd.git
cd ivd ./mcp_server/devops/setup.sh # creates .venv, installs all deps
Important: command must point at the venv's Python — setup.sh installs IVD's dependencies into .venv/, not your system Python. Using "command": "python" here will fail with ModuleNotFoundError. Replace /path/to/ivd with your actual clone path.
Cursor (Settings → Features → MCP):
{
"servers": { "ivd": { "type": "stdio", "command": "/path/to/ivd/.venv/bin/python", "args": ["-m", "mcp_server.server"], "cwd": "/path/to/ivd" } } }
VS Code / GitHub Copilot (.vscode/mcp.json):
{
"mcpServers": { "ivd": { "command": "/path/to/ivd/.venv/bin/python", "args": ["-m", "mcp_server.server"], "cwd": "/path/to/ivd" } } }
Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": { "ivd": { "command": "/path/to/ivd/.venv/bin/python", "args": ["-m", "mcp_server.server"], "cwd": "/path/to/ivd" } } }
A
pyproject.tomlnow ships in the repo (pip install .orpip install -e .
gives you an
ivd-mcpconsole command). A PyPI release (uvx ivd-mcp, no clone
required) is planned — see ROADMAP.md.
Ask your AI agent to use IVD tools. For example:
That's it. 32 of 33 tools work immediately with zero configuration — only ivd_search needs an OPENAI_API_KEY.
ivd_search requires embeddings. Generate them once (~$0.01, under a minute):
export OPENAI_API_KEY=your-key
./mcp_server/devops/embed.sh
1. You describe → what you want (natural language)
The key insight: clarification happens at the intent stage, not after code. The AI writes a verifiable contract, you approve it, then implementation is mechanical — and self-verifying.
If you already use spec-driven development (GitHub Spec Kit, OpenSpec), IVD adds what neither format provides by default: a test bound to each constraint. See docs/positioning.md.
33 tools available to any MCP-compatible AI agent (19 core + 10 Judgment tools (8 added in v3.0; ivd_judgment_check_installed and ivd_judgment_resolve added in v3.1) + 4 Canon tools added in v3.1):
| Tool | What it does |
|---|---|
ivd_get_context | Load framework principles, cookbook, or cheatsheet |
ivd_search | Semantic search across all IVD knowledge |
ivd_validate | Validate an intent artifact against IVD rules |
ivd_review_intent | Rank constraints by risk before implementation (human review gate) |
ivd_run_constraint_tests | Opt-in runner for allowlisted pytest nodes referenced by an intent |
ivd_attest | Process-attestation gate — check the agent actually *followed* the method (segmentation, re-read, coverage, joint satisfaction), not just that the artifact is well-formed |
ivd_import_spec | Parse a GitHub Spec Kit or OpenSpec spec.md into a constraint scaffold |
ivd_scaffold | Generate a new intent artifact from a template |
ivd_init | Initialize IVD in an existing project |
ivd_assess_coverage | Scan a project and report intent coverage |
ivd_load_recipe | Load a specific recipe pattern |
ivd_list_recipes | Browse all available recipes |
ivd_load_template | Load an intent or recipe template |
ivd_find_artifacts | Discover intent artifacts in a project |
ivd_check_placement | Verify artifact naming and placement |
ivd_list_features | Derive feature inventory from intent metadata |
ivd_propose_inversions | Generate inversion opportunities |
ivd_discover_goal | Help users who don't know what to ask |
ivd_teach_concept | Explain concepts before writing intent |
/.judgment/ exists*New to Judgment? Read
judgment_explained.mdfirst
— plain-English "what problem it solves and how" in 5 minutes — then the tool
table below and the runnable showcase further down will make immediate sense.
| Tool | What it does | |
|---|---|---|
ivd_judgment_init | Bootstrap .judgment/ folder + per-domain baselines | |
ivd_judgment_capture | Write a raw correction ledger entry (< 30s) | |
ivd_judgment_codify | Return a structured codify prompt for the agent | |
ivd_judgment_save_codified | Persist the agent's filled codify fields | |
ivd_judgment_pair | Capture a comparison_pair (Pearl Rung-1 alternative to A/B) | |
ivd_judgment_detect_patterns | Cluster ledger entries into patterns | |
ivd_judgment_inject_context | Prioritized judgment context for downstream agents | |
ivd_judgment_propose_recommendation | Draft recommendation against a pattern (with build/buy/hire/partner sub-types) | |
ivd_judgment_resolve | Close the loop: record an entry's resolution (outcome, whether it held) and move it `codified\ | paired → resolved`, so future runs don't re-derive a settled diagnosis. (v3.1) |
ivd_judgment_check_installed | Detect whether /.judgment/ exists. Never writes to disk — returns the ready-to-call init payload the agent must offer to the user with explicit permission. (v3.1) |
Architecture (v3.1): substance lives in the ivd/judgment/ engine package (typed @dataclass schemas; engine_version + reproducible SHA-256 hash on Pattern and InjectionResult for diffability and audit). mcp_server/tools/judgment.py is a thin facade that dispatches to the engine. Mirrors the Canon (Phase 0) architecture for symmetry. Server-level kill switch: IVD_JUDGMENT_TOOLS_ENABLED=false.
See it work. A runnable showcase walks through the full Judgment loop end-to-end — capture three real-world AI corrections, codify them, promote a Pattern, and watch the same LLM (gpt-4o-mini, temperature=0) generate different code on the same request after the Pattern enters its system message. No trust required — run it, read the terminal.
# From the ivd/ directory — runs offline, no API key required
python examples/judgment_demo/run_demo.py
OPENAI_API_KEY=sk-... python examples/judgment_demo/run_demo.py
The showcase simulates 3 weeks of an AI coding agent ignoring this project's React testing conventions across 3 different test files (PaymentForm.test.tsx, MetricsCard.test.tsx, ProfileSettings.test.tsx), feeds the 3 corrections through the 9 ivd_judgment_* tools, and writes 4 human-readable artifacts to examples/judgment_demo/output/: before.md (the agent's system message without Judgment), after.md (with the Pattern injected), diff.md (what Judgment added), and llm_responses.md (side-by-side Vitest test files with verdict).
Why this scenario: the project's testing conventions (renderWithProviders helper in src/test/test-utils.tsx, MSW server in src/test/mocks/server.ts, userEvent.setup() discipline) live ONLY in the repo. They do not exist in the LLM's training data, so a static system-prompt nudge cannot solve it — the model has to inherit the lesson from YOUR repo. That is precisely the use case Judgment is built for.
Representative result on the live LLM (gpt-4o-mini, temperature=0, n=3 trials, ~$0.001):
| Metric | Result |
|---|---|
| Framework defaults the BEFORE agent reached for | 2–3 of 3 (raw vi.fn() API mocks, bare render(), userEvent.click without setup()) |
| Project conventions the AFTER agent adopted | 3 of 3 (server.use(http.get(...)), renderWithProviders( ), const user = userEvent.setup()) |
| Project-local strings in AFTER (impossible from training data) | `renderWithProviders`, `src/test/mocks/server`, `src/test/test-utils` |
| injection_hash change (a
只显示了开头部分;其余内容请在仓库中阅读