The Yudao Pilot MCP server is a workspace-aware tool designed for the yudao/ruoyi-vue-pro ecosystem, enabling AI coding tools to accurately understand, configure, and generate code for local backend, frontend, and database projects.
Workspace Management: Load, initialize, and validate workspace configurations, ensuring project paths align with declared settings. Prevents unsafe initialization in undefined workspaces.
Project Analysis: Inspect project types using dependency fingerprints (pom.xml, package.json) without relying on directory names. Compare code generation differences between project versions (e.g., ruoyi-vue-pro vs. ruoyi-vue-pro-jdk17).
Database Integration: Resolve database configurations from workspace settings or backend local config files. Inspect table schemas from a live database, falling back to migration SQL or local schema files.
Code Generation Planning: Infer module, business name, entity name, and generation targets from a table name and workspace config. Build full code generation contexts including menu SQL data, package paths, and configuration rules.
Scaffold Generation: Generate backend (Java) and frontend (Vue) skeleton code with options to preview changes first (written to .yudao-pilot/previews/) or write directly to the project, with overwrite control and field component type overrides (e.g., inputNumber, textarea).
SQL Generation: Generate MySQL menu SQL, dictionary SQL, and H2 test SQL, with configurable options for writing to migration files and/or applying directly to the database.
File Management: Safely write AI-generated files to the correct backend or frontend project directories. Write new SQL structures as Laravel-style timestamped migration files.
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., "@yudao-pilot-mcp load workspace config and validate projects"
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.
Yudao Pilot MCP 是面向 yudao / ruoyi-vue-pro 生态的工作区感知型 MCP 服务。它帮助 AI 编码工具识别本地后端、前端、数据库和代码生成目标，让 AI 生成的代码准确落到正确项目结构里。
yudao、ruoyi-vue-pro 生态与 ruoyi / RuoYi / 若依原生生态不是同一个项目。当前 MCP 只支持 yudao、ruoyi-vue-pro、ruoyi-vue-pro-jdk17、yudao-cloud 相关项目，不支持若依原生生态项目。
让 AI 不再猜 yudao 项目目录和生成位置
用 .yudao-pilot/config.yaml 固化后端、前端和数据库配置
基于项目指纹校验路径，避免代码写错仓库或模块
生成菜单、字典、H2 测试 SQL 和前后端骨架代码
当工作目录不明确时停止初始化，并要求 AI 先询问真实项目目录
项目提供 yudao-pilot 命令入口，适合通过 pipx 或 uv 作为隔离的命令行工具安装。
推荐使用 pipx：
pipx install yudao-pilot-mcp
pipx ensurepath也可以使用 uv：
uv tool install yudao-pilot-mcp没有 pipx 或 uv 时，使用标准虚拟环境和 pip：
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install yudao-pilot-mcpWindows 使用 .venv\Scripts\activate 激活虚拟环境。如果当前 PyPI 镜像尚未同步新版本，显式使用官方索引：
python -m pip install --index-url https://pypi.org/simple/ yudao-pilot-mcp从源码安装仅用于开发：
git clone https://github.com/chanshawoh/yudao-pilot-mcp.git
cd yudao-pilot-mcp
python -m pip install -e ".[dev]"通过 pipx、uv tool 或 PATH 中的 pip 环境安装后：
{
"mcpServers": {
"yudao-pilot": {
"command": "yudao-pilot",
"args": []
}
}
}如果使用项目内虚拟环境，或 MCP 客户端读取不到 shell 的 PATH：
{
"mcpServers": {
"yudao-pilot": {
"command": "/absolute/path/to/.venv/bin/python",
"args": ["-m", "yudao_pilot.server"]
}
}
}Windows 将 command 改为 .venv\\Scripts\\python.exe 的绝对路径。临时试用也可以让 pipx 自动创建缓存环境：
{
"mcpServers": {
"yudao-pilot": {
"command": "pipx",
"args": ["run", "--spec", "yudao-pilot-mcp", "yudao-pilot"]
}
}
}长期使用推荐先执行 pipx install，避免 MCP 首次启动时等待下载依赖。
在你的 yudao 工作区中让 AI 先调用 load_workspace_config。首次使用会生成 .yudao-pilot/config.yaml，并要求确认识别到的后端和前端路径。
确认配置后，典型流程是：
load_workspace_config
validate_workspace_projects
inspect_codegen_context
generate_codegen_scaffold(write_files=true)如果用户明确要求“先预览”，则调用：
generate_codegen_scaffold(write_files=false)此时预览产物会写入 .yudao-pilot/previews/ 下的临时目录，不会影响项目现有代码。
将下面的要求交给使用该 MCP 的 AI Agent：
请安装并配置 yudao-pilot-mcp。不要克隆源码仓库，除非用户明确要参与开发。
1. 确认 Python 版本不低于 3.11。
2. 优先执行 pipx install yudao-pilot-mcp，将 MCP Server 安装为隔离的命令行工具。
3. 如果没有 pipx 但有 uv，执行 uv tool install yudao-pilot-mcp。
4. 如果两者都没有，创建 Python 虚拟环境并执行 python -m pip install yudao-pilot-mcp。
5. 如果当前包镜像找不到该包，使用 --index-url https://pypi.org/simple/ 从官方 PyPI 安装。
6. 验证 yudao-pilot 命令存在。不要把 stdio MCP Server 持续运行在测试终端中。
7. 在用户的 MCP 客户端配置中注册 command=yudao-pilot、args=[]。
8. 如果 MCP 客户端读取不到 PATH，使用虚拟环境 Python 的绝对路径，并配置 args=["-m", "yudao_pilot.server"]。
9. 配置完成后提醒用户重启或重新加载 MCP 客户端。
安装后的业务操作方式以 yudao-pilot-mcp Skill 为准，不要在安装阶段自行执行代码生成或数据库写入。本项目采用 MIT License。你可以自由使用、复制、修改、合并、发布和分发本项目，但必须保留原始版权和许可声明。软件按“原样”提供，不附带任何明示或默示担保。
Related MCP server: Builder-Proj-MCP Server
Yudao Pilot MCP is a workspace-aware MCP server for the yudao / ruoyi-vue-pro ecosystem. It helps AI coding tools understand local backend projects, frontend targets, database configuration, and code-generation routes so generated code lands in the right place.
The yudao / ruoyi-vue-pro ecosystem is not the same project as the original ruoyi / RuoYi ecosystem. This MCP currently supports yudao, ruoyi-vue-pro, ruoyi-vue-pro-jdk17, and yudao-cloud projects only. It does not support original RuoYi projects.
Stop AI tools from guessing yudao project paths
Use .yudao-pilot/config.yaml as the routing source of truth
Validate backend and frontend paths with project fingerprints
Generate menu SQL, dictionary SQL, H2 test SQL, and backend/frontend scaffolds
Refuse unsafe initialization when the project workspace is unknown
The package exposes a yudao-pilot command and is well suited to isolated CLI installation with pipx or uv.
Recommended with pipx:
pipx install yudao-pilot-mcp
pipx ensurepathWith uv:
uv tool install yudao-pilot-mcpWithout pipx or uv, use a standard virtual environment:
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install yudao-pilot-mcpOn Windows, activate with .venv\Scripts\activate. If your configured package mirror has not synchronized the release yet, use the official PyPI index:
python -m pip install --index-url https://pypi.org/simple/ yudao-pilot-mcpInstall from source only for development:
git clone https://github.com/chanshawoh/yudao-pilot-mcp.git
cd yudao-pilot-mcp
python -m pip install -e ".[dev]"After installing with pipx, uv tool, or a pip environment available on PATH:
{
"mcpServers": {
"yudao-pilot": {
"command": "yudao-pilot",
"args": []
}
}
}When using a project virtual environment, or when the MCP client cannot see your shell PATH:
{
"mcpServers": {
"yudao-pilot": {
"command": "/absolute/path/to/.venv/bin/python",
"args": ["-m", "yudao_pilot.server"]
}
}
}On Windows, set command to the absolute path of .venv\\Scripts\\python.exe. For temporary use, pipx can create a cached environment automatically:
{
"mcpServers": {
"yudao-pilot": {
"command": "pipx",
"args": ["run", "--spec", "yudao-pilot-mcp", "yudao-pilot"]
}
}
}For regular use, run pipx install first to avoid dependency downloads during the first MCP startup.
Ask the AI client to call load_workspace_config from your yudao workspace. On first use, Yudao Pilot creates .yudao-pilot/config.yaml and asks the AI to confirm detected backend and frontend paths.
After configuration is confirmed, the common flow is:
load_workspace_config
validate_workspace_projects
inspect_codegen_context
generate_codegen_scaffold(write_files=true)If the user explicitly asks to preview first, call:
generate_codegen_scaffold(write_files=false)Preview artifacts are written under .yudao-pilot/previews/ and do not touch the existing project code.
Give the following requirements to the AI Agent using this MCP server:
Install and configure yudao-pilot-mcp. Do not clone the source repository unless the user explicitly wants a development checkout.
1. Confirm that Python 3.11 or newer is available.
2. Prefer pipx install yudao-pilot-mcp to install the MCP server as an isolated CLI application.
3. If pipx is unavailable but uv is installed, run uv tool install yudao-pilot-mcp.
4. If neither tool is available, create a Python virtual environment and run python -m pip install yudao-pilot-mcp.
5. If the configured package mirror cannot find the package, install from the official index with --index-url https://pypi.org/simple/.
6. Verify that the yudao-pilot command exists. Do not leave the stdio MCP server running in the verification terminal.
7. Register the server in the user's MCP client with command=yudao-pilot and args=[].
8. If the MCP client cannot see the command on PATH, use the absolute path to the virtual-environment Python and set args=["-m", "yudao_pilot.server"].
9. Ask the user to restart or reload the MCP client after saving the configuration.
After installation, follow the yudao-pilot-mcp Skill for business operations. Do not start code generation or database writes during installation.This project is released under the MIT License. You may use, copy, modify, merge, publish, and distribute it provided that the original copyright and permission notice are retained. The software is provided “as is”, without warranty of any kind.
比较 ruoyi-vue-pro 与 ruoyi-vue-pro-jdk17 的代码生成核心实现差异。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states the comparison action but does not disclose side effects, permissions, output format, or any behavioral traits beyond the basic operation.
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, straightforward sentence that efficiently conveys the tool's purpose with no unnecessary words. It is appropriately sized and 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?
While the tool has an output schema and no parameters, the description lacks context about what 'code generation core implementation differences' entails, what the output represents, or any prerequisites (e.g., project existence). This makes it incomplete for an agent to fully understand the tool's role.
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 tool has no parameters, and schema coverage is 100%. The description does not need to explain parameters. Baseline is 4 for zero-parameter tools.
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 function: comparing code generation core implementation differences between two specific projects (ruoyi-vue-pro and ruoyi-vue-pro-jdk17). This distinguishes it from sibling tools that generate code rather than compare.
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 does it mention prerequisites or context. Sibling tools are listed but not differentiated in usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据当前上下文生成首版代码骨架，可选择只预览或直接写入工作区。
普通代码文件默认 overwrite=false，写入时若文件已存在会返回 should_stop， 由调用方询问用户是否覆盖；前端字典常量、后端错误码等合并型文件不受此限制。
field_overrides: AI 覆盖字段组件类型，格式为 {"java_field": "html_type"}， 例如 {"lng": "inputNumber", "lat": "inputNumber"}。 可用 html_type 值: input, inputNumber, textarea, editor, select, radio, checkbox, datetime, date, imageUpload, fileUpload。 backend_module_dir: 显式后端目标模块目录，支持 yudao-module-a/yudao-module-b 或 a/b。 backend_package_module: 显式 Java package module 名，例如 b；未传时使用 module_name。
| Name | Required | Description | Default |
|---|---|---|---|
| menu_name | No | ||
| overwrite | No | ||
| table_name | Yes | ||
| entity_name | No | ||
| module_name | No | ||
| write_files | No | ||
| business_name | No | ||
| parent_menu_id | No | ||
| workspace_root | No | ||
| field_overrides | No | ||
| include_backend | No | ||
| include_frontend | No | ||
| parent_menu_name | No | ||
| backend_module_dir | No | ||
| backend_package_module | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses overwrite policy, field_overrides usage, and backend module/path conventions. It could mention prerequisites like database connection, but overall adds valuable behavioral context beyond the schema.
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 6 sentences, front-loading the main purpose. It efficiently covers overwrite behavior and key parameters without unnecessary verbosity. Could be improved with bullet points for parameter details.
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 15 parameters and existing output schema, the description explains core generation behavior and some key parameters. However, it fails to clarify what the generated code skeleton includes (e.g., full project structure? specific files?) and how it relates to sibling tools like write_generated_files_tool, leaving some ambiguity.
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 carries the burden. It explains field_overrides (with valid values), backend_module_dir, and backend_package_module with examples. But many parameters (menu_name, entity_name, module_name, etc.) are left unexplained, leaving gaps for 12 out of 15 parameters.
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 generates a first version code skeleton with preview or write options. It uses a specific verb and resource, but does not explicitly differentiate from siblings like write_generated_files_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?
The description provides context on preview vs write mode, overwrite behavior, and special handling for merge files. However, it does not specify when to use this tool versus other siblings like generate_codegen_sql_tool or infer_codegen_plan_tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成 MySQL 菜单 SQL 与模块 H2 测试 SQL，可选直接写入文件，并按配置决定是否写库。
菜单/字典是否生成由工作区配置 codegen.menu_sql_mode、codegen.dict_sql_mode 控制； 是否允许写库由 codegen.apply_to_database 控制： auto（默认）= 生成 SQL，write_files 写迁移，若 apply_to_database=true 则允许写库； migration_only = 仅生成/写入迁移文件，不执行真实数据库写入； disabled = 不生成对应 SQL（不写迁移中的该段）。 backend_module_dir: 显式后端目标模块目录，支持 yudao-module-a/yudao-module-b 或 a/b。 backend_package_module: 显式 Java package module 名，例如 b；未传时使用 module_name。
| Name | Required | Description | Default |
|---|---|---|---|
| menu_icon | No | ||
| menu_name | No | ||
| overwrite | No | ||
| table_name | Yes | ||
| entity_name | No | ||
| module_name | No | ||
| write_files | No | ||
| business_name | No | ||
| parent_menu_id | No | ||
| workspace_root | No | ||
| module_menu_icon | No | ||
| module_menu_name | No | ||
| parent_menu_name | No | ||
| backend_module_dir | No | ||
| backend_package_module | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that SQL generation is controlled by workspace config (codegen.menu_sql_mode, codegen.dict_sql_mode) and that database writing depends on codegen.apply_to_database. This gives insight into side effects and conditional behavior, though details like error handling or what 'write files' entails are missing.
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 dense paragraph that front-loads the main purpose. It could be more structured (e.g., using bullet points for modes or parameter explanations) but overall is reasonably concise without excessive 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?
Given the tool's complexity (15 parameters, many optional) and lack of schema descriptions, the description does not adequately cover how to use each parameter or their interactions. While the configuration modes are explained, the roles of parameters like entity_name, business_name, and parent_menu_id are left ambiguous. The existence of an output schema is mentioned but not detailed.
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 0%, so the description must compensate for 15 parameters. It only explains two parameters (backend_module_dir, backend_package_module) with examples. The remaining 13 parameters (e.g., table_name, entity_name, menu_icon) have no description, leaving the agent to infer meaning from names alone.
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 generates MySQL menu SQL and H2 test SQL for modules, with optional file writing and database update based on configuration. This specific verb-resource combination ('generate SQL') distinguishes it from sibling tools like generate_codegen_scaffold_tool (scaffold generation) or write_mysql_migration_tool (migration writing).
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 explains the behavior in three configuration modes (auto, migration_only, disabled) and how they affect SQL generation and database writing. It provides clear context on when SQL is generated and written, but does not explicitly state when to prefer this tool over alternatives or mention prerequisites.
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 |
|---|---|---|---|
| table_name | Yes | ||
| workspace_root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the inference operation but does not disclose whether it is read-only, side-effect-free, or requires authentication/permissions. The title is null, missing an opportunity to convey behavior.
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, achieving conciseness but sacrificing detail. It is front-loaded with the core purpose. However, it could be more structured, e.g., listing inputs and outputs.
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 presence of sibling tools and the output schema (unknown content), the description is insufficient. It does not explain how the inference relates to code generation workflow, what the output contains, or prerequisites like workspace config being loaded.
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?
With 0% schema description coverage, the description must explain parameters. It mentions 'workspace configuration' but does not describe 'table_name' or 'workspace_root' explicitly. The parameter 'workspace_root' has a default null but no guidance on its role.
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 uses a specific verb 'infer' and lists the outputs (module, business name, entity name, generation target). It is clear about the tool's function and distinguishes it from siblings like 'generate_codegen_sql_tool' or 'inspect_table_schema_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 usage guidelines are provided. The description does not indicate when to use this tool vs alternatives such as 'inspect_table_schema_tool' or when not to use it. Implicitly, it is for inferring plan details, but no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
结合配置规则、后端默认配置和 SQL 菜单数据，构建生成代码所需上下文。
backend_module_dir: 显式后端目标模块目录，支持 yudao-module-a/yudao-module-b 或 a/b。 backend_package_module: 显式 Java package module 名，例如 b；未传时使用 module_name。
| Name | Required | Description | Default |
|---|---|---|---|
| menu_name | No | ||
| table_name | Yes | ||
| entity_name | No | ||
| module_name | No | ||
| business_name | No | ||
| parent_menu_id | No | ||
| workspace_root | No | ||
| parent_menu_name | No | ||
| backend_module_dir | No | ||
| backend_package_module | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool combines configuration rules and defaults to build context, suggesting a read-only operation, but it does not explicitly state if it has side effects or if it modifies any state. A score of 3 reflects this partial transparency.
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 compact with three sentences: the first defines the overall purpose, the next two detail specific parameters. It is front-loaded and efficient, though it could include more parameter information 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?
Given the tool has 10 parameters, no schema descriptions, and no annotations, the description is insufficient. It only covers two parameters and does not explain required inputs like table_name or optional ones like entity_name, menu_name, etc. An output schema exists but does not compensate for missing input guidance.
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?
With 0% schema description coverage, the description is the only source. It explains only 2 out of 10 parameters (backend_module_dir and backend_package_module) with some detail. The remaining 8 parameters are not described at all, leaving significant ambiguity.
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 builds context for code generation by combining config rules, backend defaults, and SQL menu data. This verb-resource combination is specific and distinct from sibling tools like infer_codegen_plan_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?
The description explains two parameters (backend_module_dir and backend_package_module) in detail, implying they are optional. However, it does not explicitly state when to use this tool versus alternatives like infer_codegen_plan_tool, nor specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
优先从真实数据库解析字段，缺失时回退到目标迁移 SQL 或本地结构 SQL。
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | ||
| workspace_root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the fallback strategy (real database first, then migration/local SQL), which is key behavioral information. Without annotations, this fills a gap. However, it does not mention any side effects or required permissions.
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, but it is sparse. It could be expanded to include parameter info without losing conciseness.
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?
Despite having an output schema and simple parameters, the description omits crucial details like parameter descriptions, usage context, and return value semantics. The fallback behavior is the only substantial information.
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 0%, and the description provides no information about the two parameters (table_name and workspace_root). An agent must rely solely on the schema, which lacks descriptions, leading to confusion about workspace_root's purpose.
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, combined with the tool name, clearly indicates the tool inspects table schema. It adds the fallback behavior (real DB, then migration/local SQL), which distinguishes it from generic schema tools. However, it does not explicitly state the primary purpose of returning the schema.
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 vs alternatives. The sibling tools are all code-generation related, but the description does not clarify the specific use case or prerequisites. An agent would have to infer its usage.
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 |
|---|---|---|---|
| workspace_root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 fallback behavior when the config file is missing, adding some transparency. However, it does not state whether the tool is read-only, has side effects, or requires specific permissions.
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, a single sentence that front-loads the primary action and then adds the conditional fallback behavior. It is efficient, though could benefit from slightly more structure.
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 optional parameter and the existence of an output schema, the description is too brief. It does not explain the output format, how 'workspace_root' is used, or how the tool fits into a workflow with siblings. Incomplete for a tool with this complexity.
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 0% for the only parameter 'workspace_root', and the description provides no explanation of its meaning, usage, or effect. The description fails to compensate for the lack of schema documentation.
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 loads the current workspace config and specifies the fallback behavior when the config file is missing. However, it does not explicitly differentiate from sibling tools like 'resolve_database_config_tool' or 'validate_workspace_projects_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 guidance is provided on when to use this tool vs alternatives. Missing context about prerequisites, when it is appropriate, or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
解析数据库配置，优先遵循工作区 config，其次从后端本地配置中读取。
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It only reveals a priority order but does not disclose whether the tool reads, modifies, or produces side effects. Missing information on error handling, return behavior, or safety implications.
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 18-character sentence, which is concise but underspecified. It lacks structure and depth for a tool with a non-trivial purpose, though it contains no redundant verbiage.
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 low complexity and presence of an output schema (not described), the description should cover return value semantics. It does not, nor does it explain how the priority order affects output. Incomplete for confident invocation.
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 0%, yet the description does not mention the single parameter 'workspace_root'. It fails to explain its role (e.g., specifying workspace path) or its relationship to the priority order, forcing agents to infer from the Chinese text.
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 resolves database configuration with a specific priority order (workspace config first, then backend local config). The verb '解析' and resource '数据库配置' are specific. However, it does not distinguish from siblings like load_workspace_config_tool, but the purpose is still 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?
No guidance is provided on when to use this tool versus alternatives like load_workspace_config_tool. There is no mention of prerequisites or situations where this tool should not be used, leaving the agent without contextual decision support.
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 |
|---|---|---|---|
| workspace_root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, permissions required, or whether the tool is read-only. For a validation tool, it likely has no destructive effects, but this is not stated. The description carries the full burden for transparency but fails to address it.
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, which is concise but lacks structure. It conveys the core action efficiently but omits critical context that would fit in additional sentences. It is not verbose, but it is under-specified.
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 has an output schema (context signals), the description does not need to detail return values. However, it fails to describe what 'strictly match' means, what happens on mismatch (e.g., errors or list of mismatches), or the tool's role in a workflow. The description is incomplete for effective use.
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 0%, and the description does not explain the 'workspace_root' parameter at all. The tool description adds no meaning beyond the schema, which only provides the parameter name and type. For a tool with a single optional parameter, this is a significant gap.
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: validating backend and frontend projects against configuration. It specifies the resource (workspace projects) and action (validate match). However, it could be slightly more precise about the nature of the match (e.g., 'strictly match' is vague).
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 siblings. While the name and description imply validation context, there are no exclusions, prerequisites, or alternative tool mentions. An agent would have to infer usage from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
将 AI 应用生成的文件安全写入到配置指定的后端或前端项目中。
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | ||
| workspace_root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions '安全写入' (securely write) but does not explain safety details or side effects (e.g., overwriting, permissions). The tool writes files, implying destructive potential, but no 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 concise (one sentence) but lacks structure. It conveys purpose efficiently but omits necessary details, making it adequate but not well-structured.
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 output schema exists, return values are not needed. However, the description does not explain prerequisites, configuration reference, or how the tool fits into the workflow. It is incomplete for a file-writing operation.
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 0%, and the description fails to explain the 'files' parameter structure or 'workspace_root' usage. The agent receives no additional meaning beyond the schema types, which are vague (array of objects with additionalProperties).
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 action (write files), the resource (generated files), and the target (backend/frontend project specified in configuration). It distinguishes from sibling tools that focus on code generation, comparison, and inspection. However, the term '配置指定的' (specified in configuration) is vague without context.
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 does not provide guidance on when to use this tool versus alternatives like generate_codegen_scaffold_tool or write_mysql_migration_tool. There are no explicit usage conditions or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
将新的 SQL 结构以 Laravel 风格文件名写入 sql/mysql/migrations 目录。
| Name | Required | Description | Default |
|---|---|---|---|
| overwrite | No | ||
| sql_content | Yes | ||
| migration_name | Yes | ||
| workspace_root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates file creation but lacks details on side effects, permissions, error handling, or consequences of overwriting.
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?
Single sentence, no redundancy. However, it is in Chinese and could be more structured (e.g., listing purpose, parameters).
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?
Despite having an output schema, the description does not explain return values or success/failure indicators. For a file-writing mutation tool, more context is needed.
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 0%. The description only implies meaning for migration_name and sql_content via 'Laravel-style filenames' and 'SQL structure', but overwrite and workspace_root are unexplained.
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 verb ('write') and resource ('SQL migration file'), specifies the target directory ('sql/mysql/migrations') and naming style ('Laravel-style filenames'), distinguishing it from siblings that generate SQL or scaffold code.
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 versus alternatives like generate_codegen_sql_tool. No prerequisites or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: compare references, generate scaffold, generate SQL, infer plan, init config, inspect context, inspect project path, inspect table schema, load config, resolve DB config, validate projects, write generated files, write migration. No overlap is evident.
All tool names follow a consistent verb_noun pattern with underscores, e.g., generate_codegen_scaffold_tool, inspect_table_schema_tool. Verbs are descriptive and repeated verbs (generate, inspect, write) are appropriate for different objects.
With 13 tools, the server is well-scoped for its code generation domain. Each tool serves a clear purpose, and the count is within the ideal 3-15 range for a focused server.
The tool set covers the full code generation lifecycle: configuration initialization and loading, database setup, schema inspection, plan inference, scaffold generation, SQL generation, file writing, migration, and validation. No obvious gaps are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
A MCP server built for developers enabling Git based project management with project and personal…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chanshawoh/yudao-pilot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
