Skip to main content
Glama
hotic

ProTools MCP Server

by hotic
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ProTools MCP Server

可扩展的 MCP 工具盒，封装日常开发脚本。支持代码合并、AI 代码审查等功能。

功能特性

  • 代码合并：将多个源文件合并为单一上下文，支持压缩模式

  • AI 代码审查：支持 OpenAI GPT-5.2 和 Google Gemini 3 Flash 双模型并发审查

  • 文档生成：从代码/配置变更中提取隐含规范，生成技术规范、设计决策、变更日志

  • 异步任务：长时间任务支持异步执行和轮询查询

  • 智能默认：未指定审查目标时自动检测 Git 变更

Related MCP server: code-lens

工具列表

protools_merge_files

合并多个源代码文件，供对话模型作为上下文使用。

参数

类型

默认值

说明

inputs

string[]

必填

文件/目录/glob 路径列表

mode

full | compact | skeleton

compact

压缩模式

extensions

string[]

-

过滤扩展名，如 [".ts", ".js"]

excludes

string[]

-

排除的 glob 模式

group

boolean

false

按输入路径分组输出

output

inline | file

inline

输出方式

output_dir

string

output/

输出目录

max_bytes

number

-

超过此字节数强制落盘

压缩模式：

  • full：保留全部内容

  • compact：移除注释和 import

  • skeleton：仅保留签名

protools_code_review

使用 AI 对代码进行同步审查。

参数

类型

默认值

说明

cwd

string

-

工作目录（多仓库工作区时指定项目路径）

inputs

string[]

-

文件/目录/glob 路径（与 git_mode 二选一）

git_mode

staged | unstaged | all

-

Git diff 模式（未指定 inputs 时自动启用）

include_full_files

boolean

true

Git 模式下是否包含完整文件内容

include_project_context

boolean

true

是否包含项目上下文

focus

security | performance | quality | maintainability | all

all

审查关注领域

provider

openai | gemini

-

指定单个 Provider

mode

full | compact | skeleton

compact

代码压缩模式

context

string

-

附加审查说明

output

inline | file

inline

输出方式

protools_code_review_start

启动异步代码审查任务，返回任务 ID。

参数

类型

默认值

说明

继承 protools_code_review 全部参数

providers

string[]

-

并发使用的 Provider 列表

wait_first_result_ms

number

0

等待首个结果的超时时间（毫秒）

提示：未指定 inputs 和 git_mode 时，会自动检测 Git 变更并使用 all 模式。

protools_code_review_status

查询异步代码审查任务状态。

参数

类型

说明

task_id

string

任务 ID

protools_document_suggest

从代码/配置变更中提取隐含规范，生成结构化文档。

参数

类型

默认值

说明

cwd

string

-

工作目录

inputs

string[]

-

文件/目录/glob 路径（与 git_mode 二选一）

git_mode

staged | unstaged | all

-

Git diff 模式

doc_type

spec | decision | changelog | auto

auto

文档类型

format

markdown | feishu

feishu

输出格式

language

zh | en

zh

输出语言

context

string

-

附加背景说明

provider

openai | gemini

gemini

LLM Provider

extensions

string[]

-

过滤扩展名

excludes

string[]

-

排除的 glob 模式

文档类型：

  • spec：技术规范（配置格式、字段定义、约束规则）

  • decision：设计决策（技术选型、架构权衡）

  • changelog：变更日志（按类别分组的变更记录）

  • auto：自动推断最合适的类型

输出格式：

  • feishu（默认）：针对飞书优化，避免 HTML，标题不超 3 级

  • markdown：标准 Markdown

环境变量配置

# OpenAI 配置
OPENAI_API_KEY=sk-xxx           # OpenAI API Key
OPENAI_BASE_URL=                # 可选，自定义 API 地址
OPENAI_REASONING_EFFORT=medium  # 推理级别：none | low | medium | high | xhigh

# Gemini 配置
GEMINI_API_KEY=xxx              # Google AI API Key
GEMINI_THINKING_LEVEL=HIGH      # 思考级别：NONE | LOW | MEDIUM | HIGH

# Provider 配置
LLM_PROVIDER=openai,gemini      # 默认使用的 Provider（逗号分隔）
CONCURRENT_REVIEW=true          # 是否启用并发审查
ASK_USER_FEEDBACK=false         # 是否询问用户反馈

MCP 配置示例

Claude Desktop / Cursor

{
  "mcpServers": {
    "protools": {
      "command": "node",
      "args": ["/path/to/ProTools/dist/index.js"],
      "env": {
        "OPENAI_API_KEY": "sk-xxx",
        "OPENAI_REASONING_EFFORT": "medium",
        "GEMINI_API_KEY": "xxx",
        "LLM_PROVIDER": "openai,gemini",
        "CONCURRENT_REVIEW": "true",
        "GEMINI_THINKING_LEVEL": "HIGH"
      }
    }
  }
}

开发模式（使用 tsx）

{
  "mcpServers": {
    "protools": {
      "command": "npx",
      "args": ["tsx", "/path/to/ProTools/src/index.ts"],
      "env": {
        "OPENAI_API_KEY": "sk-xxx",
        "OPENAI_REASONING_EFFORT": "medium",
        "GEMINI_API_KEY": "xxx",
        "LLM_PROVIDER": "openai,gemini",
        "CONCURRENT_REVIEW": "true"
      }
    }
  }
}

开发

# 安装依赖
npm install

# 开发运行
npm run dev

# 编译
npm run build

# 类型检查
npx tsc --noEmit

项目结构

src/
├── index.ts                 # MCP Server 入口
├── core/
│   ├── io.ts               # 文件 IO 工具
│   ├── merge.ts            # 代码合并逻辑
│   ├── git.ts              # Git 操作
│   ├── project-context.ts  # 项目上下文收集
│   └── llm/                # LLM Provider
│       ├── index.ts
│       ├── base-provider.ts
│       ├── openai-provider.ts
│       └── gemini-provider.ts
├── tools/
│   ├── merge-files.ts      # 合并文件工具
│   ├── code-review.ts      # 代码审查工具
│   ├── document-suggest.ts # 文档生成工具
│   └── review/             # 审查子模块
│       ├── task-store.ts   # 任务存储
│       ├── report-generator.ts
│       └── result-processor.ts
├── prompts/
│   ├── review-prompt.ts    # 审查 Prompt 构建器
│   ├── document-prompt.ts  # 文档 Prompt 构建器
│   └── templates/          # Prompt 模板
│       ├── review.ts
│       └── document.ts
└── types/
    ├── merge.ts
    ├── review.ts
    └── document.ts

License

MIT

Available Tools

5 tools
protools_code_reviewB

使用 AI 对代码进行审查，支持安全性、性能、质量和可维护性分析。支持 OpenAI GPT-5.2 和 Google Gemini 3 Flash。

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNo工作目录，多仓库工作区时指定要审查的项目路径（如 /home/user/Work/xxxx）
modeNo代码压缩模式：full=完整代码 | compact=移除注释和import | skeleton=仅保留类/方法签名（适合全仓库审查）compact
focusNo审查关注领域：security | performance | quality | maintainability | allall
inputsNo要审查的文件/目录/glob 路径列表（与 git_mode 二选一）
outputNo输出方式：inline=直接返回 | file=写入文件inline
contextNo附加的审查上下文或特殊说明
excludesNo排除的 glob 模式，如 ["**/test/**", "**/*.test.ts"]
git_modeNoGit diff 模式：staged=已暂存 | unstaged=未暂存 | all=全部未提交
providerNoLLM Provider，默认从 LLM_PROVIDER 环境变量读取
extensionsNo过滤扩展名，如 [".ts", ".js"]
output_dirNo输出目录（output=file 时使用）
include_full_filesNoGit diff 模式下，是否同时包含变更文件的完整内容以提供更好的上下文
include_project_contextNo是否包含项目信息（package.json、目录结构等）以帮助模型理解项目背景

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It fails to mention side effects like file writing (output=file), potential destructive actions, rate limits, or required permissions. The description is too brief for the tool's complexity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundant information. The structure is front-loaded with capabilities, then supported models. Could be improved with bullet points but remains efficient and focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 13 parameters, no annotations, and no output schema, the description is incomplete. It omits return values, error handling, prerequisites, and important behavior like file output or git mode interactions. Significant gaps for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for all 13 parameters. The description adds no extra meaning beyond the schema, so it meets the baseline of 3. No deficit, but no added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs AI code review for security, performance, quality, and maintainability. It specifies supported providers (GPT-5.2, Gemini 3 Flash), distinguishing it from sibling tools like protools_code_review_start and protools_code_review_status, but does not explicitly differentiate itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through parameters like mode and focus, but does not explicitly state when to use this tool versus alternatives (start, status) or provide exclusions. Guidance is ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

protools_code_review_startA

启动异步代码审查任务，返回任务 ID 并支持查询进度或获取部分结果。

重要：审查结果需要批判性分析

  • 不是所有报告的问题都需要修复，需根据项目实际情况判断

  • 区分真正的问题 vs 过度工程化建议（如"建议添加更多配置"）

  • INFO 级别通常可忽略，MINOR 需权衡成本，MAJOR/CRITICAL 才是重点

  • 如果多个模型报告相同问题，可信度更高

高效等待（避免轮询）

  • 设置较大的 wait_first_result_ms（如 60000）一次性等待首个结果

  • 或在查询 status 前用 Bash sleep 间隔等待（如 sleep 15）

  • 不要疯狂轮询 status，每次调用都消耗 token

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNo工作目录，多仓库工作区时指定要审查的项目路径（如 /home/user/Work/xxxx）
modeNo代码压缩模式：full=完整代码 | compact=移除注释和import | skeleton=仅保留类/方法签名（适合全仓库审查）compact
focusNo审查关注领域：security | performance | quality | maintainability | allall
inputsNo要审查的文件/目录/glob 路径列表（与 git_mode 二选一）
outputNo输出方式：inline=直接返回 | file=写入文件inline
contextNo附加的审查上下文或特殊说明
excludesNo排除的 glob 模式，如 ["**/test/**", "**/*.test.ts"]
git_modeNoGit diff 模式：staged=已暂存 | unstaged=未暂存 | all=全部未提交
providerNoLLM Provider，默认从 LLM_PROVIDER 环境变量读取
providersNo并发审查使用的 provider 列表，默认使用 LLM_PROVIDER
extensionsNo过滤扩展名，如 [".ts", ".js"]
output_dirNo输出目录（output=file 时使用）
include_full_filesNoGit diff 模式下，是否同时包含变更文件的完整内容以提供更好的上下文
wait_first_result_msNo等待首个模型结果的超时时间（毫秒），0 表示立即返回
include_project_contextNo是否包含项目信息（package.json、目录结构等）以帮助模型理解项目背景

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses async behavior, result interpretation (critical analysis needed), and polling costs. With no annotations, the description carries full burden and adequately communicates behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than necessary with multiple sections, but it is well-structured and includes important usage tips. It could be more concise without losing essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (15 parameters, async execution) and lack of output schema, the description provides high-level usage patterns but fails to specify the exact return format (e.g., task ID structure). Completeness is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with descriptions; the tool description adds no additional parameter insights beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool starts an asynchronous code review task and returns a task ID. It distinguishes itself from sibling tools like protools_code_review (likely synchronous) and protools_code_review_status (for progress queries).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides efficient waiting strategies (e.g., using wait_first_result_ms or sleep) and warns against polling. However, it does not explicitly state when to prefer this over the sync variant or other alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

protools_code_review_statusA

查询异步代码审查任务状态，可获取部分或最终结果。

注意：审查结果需批判性分析，详见 protools_code_review_start 的说明。

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYes由 protools_code_review_start 返回的任务 ID

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions partial or final results but does not disclose behavioral traits such as authentication requirements, rate limits, or whether the operation is destructive. Adequate for a simple status query.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. The first sentence front-loads the purpose, and the second provides a critical note. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description covers the basic purpose and provides a caution. However, it does not describe the format of results (e.g., JSON structure) which could be helpful, making it moderately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the description adds value by explaining that task_id is returned by protools_code_review_start, which is informative beyond the schema's minimal description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it queries the status of an asynchronous code review task, differentiating it from protools_code_review_start which initiates the task. However, it does not explicitly distinguish from the sibling tool protools_code_review, which may perform synchronous review.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after starting a task and refers to protools_code_review_start for details on critical analysis. It does not specify when not to use or provide explicit alternatives, offering moderate guidance but lacking exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

protools_document_suggestA

从代码/配置变更中提取隐含规范，生成结构化文档。

文档类型

  • spec: 技术规范（配置格式、字段定义、约束规则）

  • decision: 设计决策（为什么这么做、权衡考量）

  • changelog: 变更日志（按类别分组的变更记录）

  • auto: 自动推断最合适的类型

输出格式

  • markdown: 标准 Markdown

  • feishu: 飞书优化格式（默认，避免 HTML、标题不超 3 级）

使用示例

  • 从 Git 变更生成技术规范：git_mode="staged", doc_type="spec"

  • 从文件生成设计决策：inputs=["src/**/*.yml"], doc_type="decision"

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNo工作目录，多仓库工作区时指定项目路径
formatNo输出格式：markdown=标准 Markdown | feishu=飞书优化格式feishu
inputsNo要分析的文件/目录/glob 路径列表（与 git_mode 二选一）
contextNo附加的上下文说明，帮助 LLM 理解变更背景
doc_typeNo文档类型：spec=技术规范 | decision=设计决策 | changelog=变更日志 | auto=自动推断auto
excludesNo排除的 glob 模式
git_modeNoGit diff 模式：staged=已暂存 | unstaged=未暂存 | all=全部未提交
languageNo输出语言：zh=中文 | en=英文zh
providerNoLLM Provider，默认 gemini（格式化更好）
extensionsNo过滤扩展名，如 [".yml", ".yaml"]

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It mentions using LLM and providers, but does not discuss safety (e.g., whether it modifies files, requires specific permissions, or handles destructive actions). For a tool with 10 parameters, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for document types, output formats, and usage examples. It is not overly verbose; every section adds useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, no output schema), the description covers core functionality, parameter options, and examples. It could mention the return format (likely a document string) but is otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage, providing clear explanations for each parameter. The description adds value by grouping parameters and offering usage examples, helping understand which combinations are appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it extracts implicit specifications from code/config changes to generate structured documentation. It lists specific document types (spec, decision, changelog, auto) and output formats (markdown, feishu), distinguishing from sibling tools like code review or merge files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on when to use each doc_type and format, with examples like 'from Git staged changes generate spec'. However, it does not explicitly state when not to use this tool or compare directly to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

protools_merge_filesA

合并多个源代码文件，供对话模型作为上下文使用。支持压缩模式（full/compact/skeleton）、扩展名过滤、排除规则、分组输出。

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNo压缩模式：full=保留全部 | compact=移除注释和import | skeleton=仅保留签名compact
groupNo按输入路径分组输出
inputsYes文件/目录/glob 路径列表
outputNo输出方式：inline=直接返回内容 | file=写入文件并返回路径inline
excludesNo排除的 glob 模式列表
max_bytesNo超过此字节数强制落盘（即使 output=inline）
extensionsNo过滤扩展名，如 [".kt", ".java"]
output_dirNo输出目录，默认 ProTools/output

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details compression modes, extension filtering, exclusion rules, and output options (inline/file, max_bytes fallback), providing sufficient behavioral context. However, it lacks information on error handling, permissions, or side effects. Since no annotations are provided, the description carries the full burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with two sentences that first state the core purpose then list key features. It is front-loaded and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main functionality and modes comprehensively. However, given the absence of an output schema, it would benefit from a brief note on the return format (e.g., merged text or file path), which is only partially addressed in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the description's high-level summary adds context but does not significantly enhance individual parameter understanding beyond the schema's own descriptions. The baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function of merging source code files for use as context for dialogue models, listing specific features (compression modes, extension filtering, exclusion rules, group output). This distinguishes it from sibling tools like protools_code_review and protools_document_suggest, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for assembling code files for model context but provides no explicit guidance on when to prefer this tool over alternatives or when not to use it. No comparison to sibling tools or scenarios is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv1.0.0
    • First observedprotools_code_review
    • First observedprotools_code_review_start
    • First observedprotools_code_review_status
    • First observedprotools_document_suggest
    • First observedprotools_merge_files
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: synchronous code review, async code review initiation, status query, document generation, and file merging. No overlapping functionality, and descriptions clearly differentiate them.

Naming Consistency3/5

All tools share a common prefix 'protools_', but the verb/noun order varies: 'code_review' (noun), 'code_review_start' (noun+verb), 'document_suggest' (noun+verb), 'merge_files' (verb+noun). This mixed pattern reduces predictability.

Tool Count5/5

Five tools is a well-scoped set for a server focused on code review and documentation. No unnecessary redundancy or excessive operations.

Completeness4/5

The tool set covers core workflows: sync/async review, status tracking, documentation generation, and file merging. Missing features like review list or cancellation are minor and don't hinder common use cases.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers