yudao-pilot-mcp

by chanshawoh

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3/5 across 13 of 13 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on July 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/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 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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
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: 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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![yudao-pilot-mcp MCP server](https://glama.ai/mcp/servers/chanshawoh/yudao-pilot-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chanshawoh/yudao-pilot-mcp)

Score Badge

Copy to your README.md:

[![yudao-pilot-mcp MCP server](https://glama.ai/mcp/servers/chanshawoh/yudao-pilot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chanshawoh/yudao-pilot-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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