Uses OpenAI-compatible APIs to perform 7-dimensional architecture reviews, leveraging models like DeepSeek or GPT to generate structured vulnerability reports.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@VC_replan-mcp Perform a multi-dimensional architecture review on my new authentication system."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Architecture Review MCP Server — 7 维度架构审查 + 知识库自动沉淀。
作为 Claude Code 的"冷静建筑师 + 逻辑安全网关"，在方案落地前进行多维度审查， 自动检索 Web 情报和历史 KB 记录，输出结构化漏洞报告。
7 维度审查矩阵：Security / Performance / Architecture / Compatibility / DataIntegrity / Reliability / Observability
4 级严重度：S0 (Fatal) → S1 (Must-fix) → S2 (Warning) → S3 (Suggestion)
Web 情报检索：通过 UniFuncs API 自动搜索 + 深度阅读，注入防御过滤
双层知识库：global/（跨项目通用）+ projects/{id}/（项目专属），反向链接互通
去重机制：vuln_id 精确匹配 + keyword overlap >70% 模糊匹配
Prompt 注入防御：定界符隔离 + 12 种注入模式检测
Related MCP server: MCP Hub Security
VC_replan-mcp/
├── server.py # MCP 入口（FastMCP + stdio）
├── config.py # 环境变量加载 + API Key 脱敏
├── requirements.txt # 依赖锁定
├── models/
│ └── schemas.py # Pydantic v2 数据模型
├── engine/
│ ├── sanitizer.py # 注入检测 + 定界符包裹
│ ├── researcher.py # Web 搜索 + 深度阅读
│ ├── kb_retriever.py # KB 索引检索 + 路径安全
│ ├── kb_writer.py # 双层写入 + 去重 + 反向链接
│ ├── prompt_builder.py # 审查 Prompt 构建（7 维矩阵）
│ ├── reviewer.py # OpenAI 兼容 API 调用
│ └── parser.py # JSON 解析 + 正则兜底
├── tools/
│ ├── audit.py # 审查流水线编排
│ └── kb_update.py # KB 维护操作（5 种 action）
├── clink_core/ # CLI Bridge（claude/gemini/codex）
├── config/ # CLI 客户端配置 + 系统提示词
└── tests/ # 58 个单元/集成测试cd VC_replan-mcp
pip install -r requirements.txtcp .env.example .env
# 编辑 .env 填入实际的 API Key必填项：
REVIEWER_API_BASE — 审查模型 API 地址（OpenAI 兼容）
REVIEWER_API_KEY — 审查模型 API Key
REVIEWER_MODEL — 模型名称（如 deepseek-chat）
UNIFUNCS_API_KEY — UniFuncs Web 搜索 API Key
可选项：
KB_PATH — 知识库根目录（默认 ~/.claude/VC_planning_mcp_kb，无需配置）
KB_CLI — KB 检索使用的 CLI（claude / gemini / codex，默认 claude）
KB_AUTO_WRITE — 审查后自动写入 KB（true / false，默认 true）
KB_WRITE_S2 — S2 级别是否写入 KB（默认 true）
claude mcp add vc-replan-mcp \
-s user \
-e REVIEWER_API_BASE=https://api.deepseek.com/v1 \
-e REVIEWER_API_KEY=你的审查模型Key \
-e REVIEWER_MODEL=deepseek-chat \
-e UNIFUNCS_API_KEY=你的UniFuncs-Key \
-- python3 "/你的路径/VC_replan-mcp/server.py"文件位置：~/.claude/claude.json
在 mcpServers 字段中添加：
{
"mcpServers": {
"vc-replan-mcp": {
"command": "python3",
"args": ["/你的路径/VC_replan-mcp/server.py"],
"env": {
"REVIEWER_API_BASE": "https://api.deepseek.com/v1",
"REVIEWER_API_KEY": "你的审查模型Key",
"REVIEWER_MODEL": "deepseek-chat",
"UNIFUNCS_API_KEY": "你的UniFuncs-Key"
}
}
}
}如果
claude.json里已有其他 MCP server，把vc-replan-mcp这段加到mcpServers对象里即可，不要覆盖已有配置。
命令行添加：
claude mcp add vc-replan-mcp \
-s user \
-e REVIEWER_API_BASE=https://api.deepseek.com/v1 \
-e REVIEWER_API_KEY=你的审查模型Key \
-e REVIEWER_MODEL=deepseek-chat \
-e UNIFUNCS_API_KEY=你的UniFuncs-Key \
-- uvx vc-replan-mcp或手动写入 claude.json：
{
"mcpServers": {
"vc-replan-mcp": {
"command": "uvx",
"args": ["vc-replan-mcp"],
"env": {
"REVIEWER_API_BASE": "https://api.deepseek.com/v1",
"REVIEWER_API_KEY": "你的审查模型Key",
"REVIEWER_MODEL": "deepseek-chat",
"UNIFUNCS_API_KEY": "你的UniFuncs-Key"
}
}
}
}uvx 会自动创建隔离虚拟环境并安装依赖，无需手动
pip install。发布到 PyPI 后可直接uvx vc-replan-mcp运行。
添加后重启 Claude Code，输入 /mcp 应能看到 vc-replan-mcp 及其 2 个工具。
或直接调用测试：
请用 mcp_audit_architecture 审查一下这个方案：使用 raw SQL 拼接用户输入进行数据库查询mcp_audit_architecture7 维度架构审查，完整流水线：
输入 → 注入过滤 → 并行(Web搜索 + KB检索) → Prompt构建 → 模型审查 → 解析 → KB写入参数：
参数 | 类型 | 必填 | 说明 |
| string | ✅ | 待审查的技术方案 |
| string[] | ✅ | 技术栈关键词 |
| string | ✅ | 相关本地代码片段 |
| string | ❌ | 项目 ID（启用项目级 KB） |
mcp_kb_update知识库维护，支持 5 种操作：
Action | 说明 |
| 关联 global 条目到项目 |
| 解除关联 |
| 更新条目内容（关键词/技术栈） |
| 刷新所有反向链接 |
| 清理过期条目 |
KB_PATH/
├── global/
│ ├── Security/
│ │ ├── _index.yaml # 索引（关键词/去重/命中计数）
│ │ └── 2026-02-28_V001_sql-injection.md
│ ├── Performance/
│ └── ...
└── projects/
└── my-project/
└── Security/
├── _index.yaml
└── 2026-02-28_V001_sql-injection.md # 含 global_ref 链接Prompt 注入防御：12 种注入模式正则检测 + <<<UNTRUSTED_BEGIN>>> 定界符隔离
路径安全：Path.resolve().relative_to() 白名单校验，防止路径穿越
API Key 脱敏：日志中自动遮蔽（sk-****xyz）
事务性写入：先写 .md，再更新 _index.yaml，失败时回滚
python -m pytest tests/ -v58 个测试覆盖：sanitizer / researcher / kb_writer / kb_update / prompt_builder / parser / 端到端集成。
Python 3.10+
MCP Python SDK (FastMCP)
Pydantic v2（数据校验 + JSON Schema）
OpenAI SDK（兼容任意 OpenAI API 格式的模型）
PyYAML（KB 索引管理）
MIT
Architecture review — 7-dimension matrix scan with web intelligence and KB history.
Args: proposed_solution: The technical solution text to review. tech_stack_keywords: Core tech/framework keywords for intelligence retrieval. relevant_local_context: Relevant local code snippets (caller must supply). project_id: Optional project identifier for project-level KB.
Returns: Structured vulnerability list with severity, matrix coverage, and audit metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| proposed_solution | Yes | ||
| tech_stack_keywords | Yes | ||
| relevant_local_context | Yes | ||
| project_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the tool performs a scan and returns a vulnerability list, implying a read-only audit. However, it does not disclose potential side effects, permissions needed, or whether the tool modifies any state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a brief summary and a well-organized Args list. It is front-loaded with the core purpose. Minor waste: the 'Args:' line could be integrated, but overall structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description adequately explains the inputs and outputs. It mentions the tool uses web intelligence and KB history, but lacks examples or detailed methodology. Still, it covers the essential information for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description's Args section explains each parameter (proposed_solution, tech_stack_keywords, etc.) in plain language, adding meaning beyond the schema titles. This effectively compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an architecture review using a 7-dimension matrix scan with web intelligence and KB history. It distinguishes itself from the sibling tool mcp_kb_update, which suggests a different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (architecture review) and lists required parameters. However, it does not explicitly exclude scenarios or mention alternatives, though the sibling tool is a different function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Knowledge base maintenance — manage global ↔ project links and content.
Args: action: One of: link, unlink, refresh_links, update_content, cleanup_stale. global_vuln_id: Target vulnerability ID (for link/unlink/update_content). global_category: Category directory (e.g. Security). project_id: Target project ID (for link/unlink). project_kb_file: Project KB file relative path (for link). content_patch: Content update patch (for update_content).
Returns: Operation result with affected entries and summary.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| global_vuln_id | No | ||
| global_category | No | ||
| project_id | No | ||
| project_kb_file | No | ||
| content_patch | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists possible actions (link, unlink, refresh_links, update_content, cleanup_stale) and returns, but does not disclose behavioral traits such as whether actions are destructive, authorization requirements, or side effects (e.g., unlink or cleanup_stale deleting data). Some transparency, but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a docstring format with a one-line summary followed by clear Args and Returns sections. Every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema or annotations, the description provides a solid overview of actions, parameters, and return type. However, it lacks details on how 'cleanup_stale' works, error handling, or prerequisites, which would make it fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for most parameters by specifying usage contexts (e.g., 'global_vuln_id: Target vulnerability ID (for link/unlink/update_content)'). However, 'content_patch' is only described as 'Content update patch', lacking detail on format or structure, which prevents a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as managing global↔project links and content for knowledge base maintenance. It specifies a verb ('manage') and resource ('global ↔ project links and content'), and the sibling tool 'mcp_audit_architecture' is distinct, so differentiation is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for knowledge base operations but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The sibling tool 'mcp_audit_architecture' is not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.9mcp_audit_architecturemcp_kb_updateThe two tools have entirely distinct purposes: one audits architecture for vulnerabilities, the other manages knowledge base links and content. There is no overlap in functionality.
Both tool names follow the consistent pattern 'mcp_verb_noun' (audit_architecture, kb_update), with consistent use of underscores and clear verb-noun structure.
With only 2 tools, the server feels under-scoped for a tool named 'VC_replan-mcp' which suggests a replanning capability. The tools cover only auditing and KB maintenance, lacking core replanning operations.
The tool surface is severely incomplete for the implied domain of VC replanning. There are no tools to create, modify, or execute plans; only an audit tool and a KB management tool exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Governance layer for AI coding agents: knowledge-graph grounding, session audit, policy controls.
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Architecture-grounded query for AI agents. Governance constraints, system dependencies, evidence.
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/VCnoC/VC_replan-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
