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., "@Code Audit MCP Server scan D:/my-project for security vulnerabilities"
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.
AI原生代码安全审计 MCP Server
支持多语言AST分析、调用图分析、漏洞检测和AI深度审计
Related MCP server: vibecode-checker
Code Audit MCP Server 是一个基于 Model Context Protocol (MCP) 的 AI 原生代码安全审计工具。它可以与 Claude、Cursor、CatPaw 等 AI 编辑器无缝集成，提供专业的代码安全审计能力。
🚀 零配置集成 - 一行配置即可在 AI 编辑器中使用
🔍 深度分析 - 基于 AST 的代码语义分析，不仅仅是正则匹配
🛡️ 全面覆盖 - 支持 OWASP Top 10 和 CWE 常见漏洞类型
📋 可操作性强 - 每个漏洞都附带详细的复现步骤和修复建议
🤖 AI 增强 - 可选的 AI 深度审计功能
支持主流编程语言的代码安全审计：
语言 | AST解析 | 调用图 | 数据流 |
Python | ✅ | ✅ | ✅ |
JavaScript | ✅ | ✅ | ✅ |
TypeScript | ✅ | ✅ | ✅ |
Go | ✅ | ✅ | 🔄 |
Java | ✅ | ✅ | 🔄 |
PHP | ✅ | 🔄 | 🔄 |
内置 25+ 条安全检测规则，覆盖：
注入类漏洞: SQL注入、命令注入、代码注入、LDAP注入等
认证授权: 身份认证绕过、权限提升、会话管理等
数据安全: 敏感数据泄露、硬编码密码、弱加密等
其他漏洞: XSS、SSRF、XXE、路径遍历、反序列化等
自动构建代码的函数调用关系图，帮助理解：
函数之间的调用关系
数据在函数间的流动路径
潜在的攻击面
追踪用户输入到敏感函数的数据传播路径：
识别用户输入点（source）
追踪数据传播过程
发现到达危险函数的路径（sink）
每个检测到的漏洞都会生成详细的复现指南：
漏洞概述和影响范围
详细复现步骤
攻击载荷示例
Python PoC 代码
修复建议
支持多种报告输出格式：
Markdown - 适合人工阅读
JSON - 适合程序处理
SARIF - GitHub Code Scanning 兼容格式
Node.js >= 18.0
npm >= 9.0
直接下载
[https://github.com/czx1111/Code-audit-MCP]
cd code-audit-mcp-server-main
npm install && npm run build
### 验证安装
```bash
# 运行测试
node dist/index.js --version编辑 Claude Desktop 配置文件：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
添加以下内容：
{
"mcpServers": {
"code-audit": {
"command": "node",
"args": ["/path/to/code-audit-mcp-server/dist/index.js"]
}
}
}编辑 Cursor 配置文件：
macOS/Linux: ~/.cursor/mcp.json
Windows: %APPDATA%\Cursor\mcp.json
{
"mcpServers": {
"code-audit": {
"command": "node",
"args": ["D:/yourpath/code-audit-mcp-server/dist/index.js"]
}
}
}打开 CatPaw 设置 -> MCP Servers -> 添加新服务器：
{
"name": "code-audit",
"command": "node",
"args": ["/path"]
}工具名称 | 功能描述 |
| 完整代码安全审计扫描 |
| 快速扫描（仅高危漏洞） |
| 单文件深度分析 |
| 构建函数调用图 |
| 数据流分析 |
| 依赖安全检查 |
| 获取漏洞复现指南 |
最常用的功能，对整个项目进行全面的安全审计：
参数说明：
targetPath: 代码路径（文件或目录）
language: 编程语言，默认 auto 自动检测
mode: 扫描模式
quick - 快速模式，仅扫描关键文件
standard - 标准模式（默认）
deep - 深度模式，包含 AI 分析
scope: 扫描范围
all - 全部检查
security - 仅安全漏洞（默认）
quality - 代码质量
architecture - 架构分析
outputFormat: 输出格式 markdown | json | sarif
使用示例：
请使用 audit_scan 扫描 d:/my-project 目录的代码安全性适合 CI/CD 流程，仅检测 Critical 和 High 级别漏洞：
请使用 audit_quick_scan 快速扫描 d:/my-project深入分析单个文件的安全问题：
请使用 audit_analyze_file 分析 d:/my-project/app.py 文件生成函数调用关系图：
请使用 build_call_graph 构建 d:/my-project 的调用图追踪数据流动路径：
请使用 analyze_data_flow 分析 d:/my-project 的数据流当发现漏洞后，获取详细的复现操作：
请使用 get_exploitation_guide 获取 SQL_INJECTION 漏洞的复现指南# 代码安全审计报告
## 📊 扫描摘要
- 扫描文件: 15 个
- 发现漏洞: 3 个
- Critical: 1 个
- High: 1 个
- Medium: 1 个
## 🔴 Critical: SQL 注入
**文件**: src/db.py
**位置**: 第 42 行
**代码**: `query = f"SELECT * FROM users WHERE id = {user_id}"`
### 漏洞描述
直接将用户输入拼接到 SQL 查询中，可能导致 SQL 注入攻击。
### 复现步骤
1. 访问 /user?id=1
2. 输入测试载荷: 1' OR '1'='1
3. 观察是否返回异常数据
### 修复建议
使用参数化查询：
```python
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
---
## 支持的漏洞类型
### 注入类漏洞
| 漏洞类型 | CWE 编号 | 严重程度 | 检测能力 |
|---------|---------|---------|---------|
| SQL 注入 | CWE-89 | 🔴 Critical | ✅ |
| 命令注入 | CWE-78 | 🔴 Critical | ✅ |
| 代码注入 | CWE-94 | 🔴 Critical | ✅ |
| LDAP 注入 | CWE-90 | 🟠 High | ✅ |
| XPath 注入 | CWE-91 | 🟠 High | ✅ |
| NoSQL 注入 | - | 🟠 High | ✅ |
| 模板注入 | CWE-94 | 🔴 Critical | ✅ |
### 认证授权漏洞
| 漏洞类型 | CWE 编号 | 严重程度 | 检测能力 |
|---------|---------|---------|---------|
| 身份认证绕过 | CWE-287 | 🔴 Critical | ✅ |
| 权限提升 | CWE-269 | 🟠 High | ✅ |
| 会话管理问题 | CWE-384 | 🟠 High | ✅ |
| 不安全的直接对象引用 | CWE-639 | 🟠 High | ✅ |
### 数据安全漏洞
| 漏洞类型 | CWE 编号 | 严重程度 | 检测能力 |
|---------|---------|---------|---------|
| 敏感数据泄露 | CWE-200 | 🟠 High | ✅ |
| 硬编码密码 | CWE-798 | 🟡 Medium | ✅ |
| 不安全的加密 | CWE-327 | 🟡 Medium | ✅ |
| 日志注入 | CWE-117 | 🟡 Medium | ✅ |
### 其他漏洞
| 漏洞类型 | CWE 编号 | 严重程度 | 检测能力 |
|---------|---------|---------|---------|
| XSS（跨站脚本） | CWE-79 | 🟠 High | ✅ |
| SSRF（服务端请求伪造） | CWE-918 | 🟠 High | ✅ |
| XXE（XML外部实体） | CWE-611 | 🟠 High | ✅ |
| 路径遍历 | CWE-22 | 🟠 High | ✅ |
| 不安全的反序列化 | CWE-502 | 🔴 Critical | ✅ |
| 开放重定向 | CWE-601 | 🟡 Medium | ✅ |
---
## 项目结构
code-audit-mcp-server/
├── 📁 src/ # 源代码
│ ├── 📄 index.ts # MCP 工具入口
│ ├── 📄 types.ts # 类型定义
│ ├── 📄 constants.ts # 常量配置
│ ├── 📄 exploitation-guide.ts # 漏洞复现指南生成
│ ├── 📄 sarif.ts # SARIF 格式输出
│ ├── 📄 rules-loader.ts # YAML 规则加载
│ ├── 📁 parsers/ # AST 解析器
│ │ ├── 📄 types.ts # 解析器接口
│ │ ├── 📄 python.ts # Python 解析器
│ │ ├── 📄 javascript.ts # JavaScript 解析器
│ │ ├── 📄 typescript.ts # TypeScript 解析器
│ │ ├── 📄 go.ts # Go 解析器
│ │ ├── 📄 java.ts # Java 解析器
│ │ └── 📄 php.ts # PHP 解析器
│ ├── 📁 detectors/ # 漏洞检测引擎
│ │ └── 📄 engine.ts
│ ├── 📁 ai/ # AI 分析模块
│ │ └── 📄 analyzer.ts
│ └── 📁 utils/ # 工具函数
│ └── 📄 helpers.ts
├── 📁 rules/ # 安全规则（YAML）
│ └── 📄 security-rules.yaml # 安全检测规则
├── 📁 test-vulnerable-code/ # 测试用例（有漏洞的代码）
├── 📁 test-project/ # 测试项目
├── 📄 package.json # 项目配置
├── 📄 tsconfig.json # TypeScript 配置
├── 📄 LICENSE # MIT 许可证
└── 📄 README.md # 项目文档
---
## 开发指南
### 本地开发
```bash
# 安装依赖
npm install
# 开发模式（热重载）
npm run dev
# 构建生产版本
npm run build
# 运行测试
npm test
# 代码检查
npm run lint在 rules/security-rules.yaml 中添加自定义检测规则：
rules:
- id: CUSTOM_CHECK
name: 自定义安全检查
description: 检测自定义的安全问题
severity: medium
languages:
- python
- javascript
patterns:
- pattern: "dangerous_function($VAR)"
message: 发现危险函数调用在 src/parsers/ 目录下添加新的语言解析器：
// src/parsers/rust.ts
export class RustParser implements Parser {
async parse(code: string, filePath: string): Promise<ParseResult> {
// 实现 Rust AST 解析
}
}本项目采用 MIT 许可证。
欢迎提交 Issue 和 Pull Request！
⭐ 如果这个项目对你有帮助，请给一个 Star！⭐
欢迎大家关注微信公众号，获取更多技术分享。
分析代码中的数据流，追踪用户输入到敏感函数的数据传播路径。
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | 指定编程语言 | |
| entryPoint | No | 入口函数名称 | |
| targetPath | Yes | 要分析的代码路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral traits such as destructive actions, rate limits, or side effects. It only states the basic purpose without disclosing how the analysis is performed or what effects it has.
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 a single concise sentence that efficiently captures the tool's purpose with no unnecessary words.
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 the complexity of data flow analysis across multiple languages and no output schema or annotations, the description fails to explain return values, depth, limitations, or how results are presented.
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?
All three parameters are described in the schema, so the baseline is 3. The description adds context about user input and sensitive functions, but does not significantly enhance understanding beyond the schema.
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 it analyzes data flow and tracks propagation from user input to sensitive functions, distinguishing it from sibling tools like build_call_graph or check_dependencies.
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 data flow analysis but does not explicitly state when to use or not use this tool vs. alternatives, nor mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
对单个文件进行详细的代码安全分析，包括AST解析、函数提取和漏洞检测。
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | 要分析的文件路径 | |
| language | No | 指定编程语言 | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It adds behavioral context by specifying the analysis includes AST parsing, function extraction, and vulnerability detection, which is useful and implies a read-only operation. However, it does not disclose side effects, permissions, or output format.
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 a single, efficient sentence that conveys the tool's purpose and key capabilities without any waste.
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?
For a complex analysis tool with no output schema, the description gives a good overview of what the tool does internally. However, it lacks information about return values or output structure, leaving some ambiguity for the agent.
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 description coverage is 100% for both parameters (filePath and language), so baseline is 3. The description does not add additional parameter-specific meaning beyond what the schema already provides.
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 detailed code security analysis on a single file, listing specific operations (AST parsing, function extraction, vulnerability detection), which distinguishes it from siblings like 'audit_quick_scan' or 'audit_scan'.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for detailed single-file analysis but does not mention exclusions or refer to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
快速扫描，仅检测critical和high级别的漏洞。适合CI/CD流程中的快速检查。
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | 指定编程语言 | auto |
| targetPath | Yes | 要扫描的代码路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description takes full burden. It discloses the scope (only critical/high vulnerabilities) and speed, which are key behaviors. It does not mention read-only nature or other side effects, but for a scan tool this is acceptable.
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 very concise with two short, front-loaded sentences. Every word adds value with no wasted content.
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 the simplicity and lack of output schema, the description adequately covers purpose, scope, and usage context. It could mention output format, but not essential for a quick scan 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?
Schema coverage is 100%, so the description doesn't need to add much. The description adds no extra meaning beyond the schema for the two parameters (targetPath, language). Baseline score of 3 is appropriate.
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 a quick scan focusing only on critical and high-level vulnerabilities. It effectively distinguishes from sibling tools like audit_scan, which likely performs a full scan.
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 explicitly states it is suitable for quick checks in CI/CD pipelines, providing clear context for when to use it. However, it does not explicitly state alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行完整的代码安全审计扫描，包括AST解析、漏洞检测和报告生成。支持Python、JavaScript、TypeScript、Go、Java、PHP等多种语言。
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 扫描模式：quick(快速扫描高危漏洞)、standard(标准扫描)、deep(深度扫描) | standard |
| scope | No | 扫描范围 | security |
| language | No | 指定编程语言，默认自动检测 | auto |
| maxFiles | No | 最大扫描文件数 | |
| targetPath | Yes | 要扫描的代码路径（文件或目录） | |
| outputFormat | No | 输出格式 | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes scanning and analysis but does not disclose whether the tool is read-only, resource-intensive, or requires specific permissions. The lack of detail on side effects or constraints leaves the agent underinformed.
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 a single sentence that efficiently conveys the main purpose and supported languages. It is front-loaded with the key action. However, it could be more structured (e.g., bullet points for languages) to improve scannability.
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 the tool's complexity (6 parameters, 4 enums, no output schema or annotations), the description is too sparse. It does not explain the output format beyond the parameter, nor the implications of different modes/scopes. The tool's full behavior is not adequately described.
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 100% with clear descriptions for all 6 parameters. The tool description adds marginal value beyond the schema (e.g., mentioning supported languages, but that's already in the schema's 'language' enum). Baseline score of 3 is appropriate given high schema coverage.
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 a complete code security audit with AST parsing, vulnerability detection, and report generation. However, it does not distinguish itself from sibling tools like 'audit_quick_scan' or 'audit_analyze_file', which could lead to confusion about when to use this tool.
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?
No explicit guidance is provided on when to use this tool versus its alternatives (e.g., quick scans, per-file analysis, data flow analysis). The description implies a comprehensive scan, but lacks context on prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
构建代码的函数调用关系图，用于分析代码结构和数据流。
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | 指定编程语言 | |
| maxDepth | No | 调用图的最大深度 | |
| targetPath | Yes | 要分析的代码路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as permissions, side effects, or whether it is read-only. It only describes the high-level purpose.
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 one efficient sentence with no wasted words. It conveys the core purpose without redundancy.
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?
No output schema exists, and the description does not explain what the tool returns (e.g., graph format). It also lacks differentiation from the sibling tool analyze_data_flow, making it incomplete for an agent.
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 100% with descriptions for each parameter. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
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 builds a function call graph for code structure and data flow analysis, which is specific and distinguishes it from sibling tools like audit tools or dependency checkers.
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?
No guidance on when to use this tool instead of siblings (e.g., analyze_data_flow), nor any prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查项目依赖的安全风险，包括已知漏洞的依赖版本检测。
| Name | Required | Description | Default |
|---|---|---|---|
| targetPath | Yes | 项目根目录路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the purpose but omits behavioral traits such as whether network access is required, if it modifies anything, or the time cost. Minimal disclosure.
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 a single sentence, concise and front-loaded with the core purpose. It could benefit from additional details without becoming verbose.
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?
No output schema is provided, and the description does not explain what the tool returns (e.g., list of vulnerabilities, summary). This leaves a significant gap for such a simple 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?
Schema coverage is 100% with a clear description of the targetPath parameter. The tool description adds no extra meaning beyond the schema, meeting the baseline.
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 checks project dependencies for security risks, specifically known vulnerabilities. However, it does not differentiate from sibling tools like audit_scan or audit_quick_scan that may also deal with security.
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?
No guidance is provided on when to use this tool versus alternatives. The description only states the function without context on use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取漏洞的详细复现操作指南，包括攻击载荷、PoC代码和修复建议。
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | 编程语言 | python |
| vulnerabilityType | Yes | 漏洞类型（如SQL_INJECTION、COMMAND_INJECTION、XSS等） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must handle behavioral disclosure. It does not state whether the operation is read-only, requires authentication, or has side effects. The description only lists content of the guide, lacking behavioral context.
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?
A single concise sentence that efficiently conveys the tool's purpose and output contents. No unnecessary words, but could potentially be more structured with separate sections.
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 no output schema and no annotations, the description is incomplete. It does not explain the output format, whether the guide is text, file, or other, nor any constraints like size or pagination for a tool that returns a guide.
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 100% with descriptions for both parameters. The tool description adds meaning about the guide's contents but does not elaborate on individual parameters beyond what the schema provides. Baseline 3 is appropriate.
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: obtaining a detailed exploitation guide for vulnerabilities, including payloads, PoC code, and repair suggestions. The verb 'get' and resource 'exploitation guide' are specific, and it is distinct from sibling tools like analysis and scanning tools.
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 no guidance on when to use this tool versus alternatives, nor conditions or prerequisites. Although sibling tools are different, no explicit when-to-use or when-not-to-use information is given.
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.
v1.0.0analyze_data_flowaudit_analyze_fileaudit_quick_scanaudit_scanbuild_call_graphcheck_dependenciesget_exploitation_guideTools have distinct purposes overall, but some overlap exists between audit_quick_scan and audit_scan (quick subset of full scan) and between analyze_data_flow and build_call_graph (both related to code analysis). Descriptions help differentiate, but agents might occasionally misselect.
Naming is mixed: 'audit_' prefix is used inconsistently (audit_analyze_file combines verbs), and verbs vary (analyze, audit, build, check, get). While readable, there is no strict verb_noun pattern throughout.
With 7 tools, the server is well-scoped for a code audit domain. Each tool covers a necessary function without bloat, and the count is appropriate for the complexity of the domain.
The tool set covers major aspects of code auditing: scanning (full/quick/single file), data flow analysis, call graph, dependency checking, and exploitation guides. Minor gaps like a dedicated report listing are absent but not critical for typical workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MCP server for static security analysis of Android source code
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/czx1111/Code-audit-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server