PDM MCP Server

by Can-Y

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.0
Disambiguation4/5
Tools are mostly distinct, but power_design and power both deal with power data, and project includes power export functions. Descriptions clarify usage, so only minor confusion possible.
Naming Consistency5/5
All tool names are single lowercase words or underscore, following a consistent noun-based pattern. No mixed conventions.
Tool Count5/5
11 tools is well-scoped for a comprehensive power design management server, covering sessions, projects, power, clocks, IP, and more without being overwhelming.
Completeness4/5
Most essential operations are covered, including project lifecycle, power analysis, scenario management, and Vivado integration. Minor gaps exist, such as no dedicated tool for block management or voltage rail settings.
Average 4/5 across 11 of 11 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- 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?
No annotations are present, so the description carries full burden. It mentions actions and their effects only briefly (e.g., 'reset' clears all data), but lacks details on side effects, permissions, or error 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 structured as a list of actions and arguments, but is somewhat lengthy. The overall purpose is stated upfront, but some redundancy exists.
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 15 parameters and no schema descriptions, the description leaves many gaps. It does not explain return values or error handling, and the output schema is not leveraged.
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 0% schema description coverage, the description provides inline parameter hints per action (e.g., open(path), create(name, part, output_dir)), partially compensating. However, not all schema parameters are linked to actions.
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 is a unified PDM project operation entry and lists all supported actions. It distinguishes itself from sibling tools by being the central project operations hub.
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 lists actions but provides no guidance on when to use this tool versus alternatives like 'power_design' or 'estimate'. No decision criteria or exclusions 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 provided, so the description must fully disclose behavioral traits. It mentions that set_consolidation requires the mode parameter, but it does not describe side effects, authentication needs, rate limits, or what happens if the action is invalid.
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 reasonably concise, with a clear front-loaded summary followed by parameter details. It could be slightly more structured, but it effectively communicates the 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?
The tool has an output schema but the description does not mention return values. It covers the four actions and parameter dependencies, but it does not address prerequisites like session existence or error behavior, leaving some gaps.
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?
Schema description coverage is 0%, so the description must compensate. It explains the purpose of each action and specifies that mode is only used for set_consolidation, and session_id is the target session ID. However, it does not detail allowed values or formats for mode.
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 is a comprehensive tool for power design, listing four specific actions (info, rail_characteristics, delivery_design, set_consolidation) that define its purpose. It is distinct from siblings like 'power' which likely focuses on a single aspect.
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 provides usage context by detailing each action and its purpose, but it does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that import_report caches data for compare and that compare marks >10% differences. However, it does not disclose side effects (e.g., overwriting PDM data), error handling, authentication needs, or rate limits. The behavioral details are partial.
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 structured with action definitions and parameter lists, but it is verbose and mixes Chinese and English, which may reduce clarity. Some information (e.g., the first line in Chinese) is redundant. It could be more concise while maintaining completeness.
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 tool's complexity (three actions, six parameters), the description covers basic usage but lacks details on output format, error handling, and prerequisites. The presence of an output schema reduces the need to explain return values, but the description still feels incomplete for a multi-action 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?
Schema description coverage is 0%, so the description must add meaning. It explains report_path, label, util_report_path, and block_name with context. However, session_id is mentioned without explanation, and default values are not clarified. The description adds some value but does not fully compensate for the lack of schema descriptions.
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 identifies the tool as a Vivado import and comparison tool with three specific actions (import_report, compare, import_utilization). It uses specific verbs and resources. However, it does not explicitly differentiate from sibling tools like 'estimate' or 'power_design', which could overlap in functionality.
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 contexts for each action (e.g., import_report for analysis, compare for difference detection) but lacks explicit guidance on when to use this tool vs alternatives. No exclusion criteria or prerequisites are mentioned. The description is adequate but not directive.
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 full burden. It discloses the operations and parameters but does not mention side effects, authorization needs, rate limits, or behavioral traits beyond the listed actions.
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 clear sections for clock and clock manager operations, and front-loads the purpose. It is slightly verbose but organized for readability.
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 high complexity (13 parameters, many actions) and presence of an output schema, the description is fairly complete. It covers all actions and parameters, though it lacks explanation of default values, error handling, or operation ordering.
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 schema description coverage at 0%, the description compensates by explaining each parameter in the context of actions (e.g., 'freq: 时钟频率 (MHz)'). This adds significant meaning beyond schema titles. However, some parameters like 'session_id' are only listed in the args section without per-action context.
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 identifies the tool as a unified clock management tool ('统一时钟管理工具') and enumerates all specific operations (list, create, delete, edit, etc.) for both clocks and clock managers. This distinguishes it from siblings like 'session' or 'power_design'.
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 lists actions and their parameters, implying usage for clock management tasks. However, it lacks explicit guidance on when to use this tool versus alternatives, and does not provide exclusion criteria or prerequisites.
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 must fully disclose behavioral traits. It mentions destructive actions like 'delete' without any warning about irreversibility or required permissions. For a management tool with create/delete capabilities, this is a significant gap in transparency.
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 brief yet complete, structured as a bullet list under 'Args:'. Every sentence serves a purpose: the opening line states the tool's scope, and the list enumerates actions concisely. No redundant 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 that an output schema exists, return values are not needed. The description covers all actions and parameter dependencies. However, it does not address error handling, default values (e.g., session_id defaults to 'default' but not mentioned), or the fact that some required parameters per action are not marked as required in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 and does fully compensate. It explicitly lists each action value with its required parameters (e.g., 'create: 创建 IP 实例（需 ip_type + ip_name）') and provides example values for ip_type. This adds crucial meaning beyond the bare schema.
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 '综合 IP 管理工具' (comprehensive IP management tool) and lists six distinct actions (types, list, create, delete, settings, sample_settings) with specific verbs and resources. This specificity distinguishes it from sibling tools like session, power_design, or vivado, which focus on other subsystems.
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 outlines each action's required parameters, implicitly guiding when to use each action (e.g., create requires ip_type+ip_name). However, it does not explicitly state when to use this tool versus alternatives, nor does it provide 'when not to use' 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?
Discloses one behavioral trait: summary automatically saves snapshots per call. However, with no annotations provided, the description could better indicate side effects, auth needs, or whether operations are read-only. Lacks comprehensive 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?
Well-organized with a lead sentence, bullet list of subfunctions, and an args section. Every sentence earns its place, though slightly verbose; could be tightened slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, multiple modes) and the presence of an output schema (unshown), the description covers all subfunctions and parameters sufficiently, leaving no gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions coverage is 0%, yet the description explains each parameter's role (action, block_name, output_path, format, session_id) and defaults, adding crucial meaning beyond the schema.
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?
Description clearly states the tool is for unified power query/export, listing all subfunctions (summary, block_power, rails, thermal, clock_power, export_report) with brief explanations, making purpose highly specific and distinguishable from siblings.
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?
Provides context for each action and its required parameters (e.g., block_name for block_power), but does not explicitly mention when to use this tool over alternatives like power_design or estimate, nor does it state when not to use.
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?
The description discloses behavioral traits like the need to call recalculate after modifications and the dependency on power(action='summary') for compare. No annotations are provided, so the description carries full burden. It lacks details on side effects, reversibility, or rate limits.
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 well-structured with a clear opening, bulleted actions, and parameter lists. Every sentence serves a purpose, and it is concise given the complexity of 6 actions and 13 parameters.
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?
For a multi-action tool with conditional parameters, the description covers all actions' inputs and notes cross-dependencies (e.g., compare requires power snapshots). It omits output schema details but that is acceptable given output schema exists. Slight miss on not describing return structure for recalculate or set operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining each parameter's purpose, constraints (e.g., pct 0-100, lut default -1), and per-action grouping. This adds significant meaning beyond the raw schema.
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 defines the tool as a unified scenario management entry point with specific actions, each described with verb and resource. It distinguishes from sibling tools like power, estimate, and session by focusing on scenario parameter manipulation.
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 explicitly lists each action and its required/optional parameters, guiding the agent on when to use each. However, it does not provide exclusions or contrast with sibling tools for when not to use this 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?
No annotations are provided, so the description bears full responsibility. It discloses that quick estimation is based on a linear model, returns in seconds, and has ±40% accuracy. It also provides default values for parameters. However, it does not mention error conditions, idempotency, or permission requirements.
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 a summary line, action sections, and parameter lists. It is front-loaded with the main purpose. However, it is lengthy due to detailed parameter explanations; some default values are redundant with the schema, but overall efficient.
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 of the tool (21 parameters, three modes) and the presence of an output schema, the description is fairly complete. It covers all actions and parameters, though it could mention how the output varies by action or handle error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, yet the description comprehensively explains every parameter for 'quick' and 'recommend' actions, including units, defaults, and value ranges (e.g., lut_pct 0-100). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does three distinct operations: quick power estimation, part recommendation, and listing families. It uses specific verbs and resource targets, and although it doesn't explicitly differentiate from siblings, the action-based design implies distinct use cases.
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 clear context for each action, such as when to use 'quick' (rough estimation) vs 'recommend' (part selection). However, it lacks explicit guidance on when not to use this tool or alternatives among sibling tools like 'power' or 'explore'.
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?
No annotations are provided, so the description carries full burden. It details each action's behavior and parameters, though it does not cover side effects, auth requirements, or rate limits. Still, it provides adequate transparency for an exploration tool.
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 a clear intro and a bullet-style list of actions. It is longer but each sentence adds value. Could be slightly more concise, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, multiple actions), the description is comprehensive. It covers all actions and parameters clearly. An output schema exists, so return values are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose in the context of each action. For example, block is used in block_* actions, resource in resource_* actions, and fields valid values.
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 is a unified exploration entry point with sub-functions selected by action parameter. Each action is explicitly listed with its purpose, distinguishing it from sibling tools that have different functionalities.
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 explicit guidance on when to use each action through the action list. It does not include when-not-to-use or alternatives, but the context is clear enough for an agent to select the correct action.
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?
No annotations are provided, so the description carries the full burden. It discloses the step-by-step behavior, the interaction pattern, and the return of a next question with options. It also explains parameter roles. It does not cover destructive side effects, but that seems irrelevant for a wizard.
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 well-structured: a concise definition, interaction explanation, a detailed but not bloated example flow, and parameter details. Every sentence adds value, and the most important information (purpose and usage pattern) appears first.
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 wizard's complexity and 0% schema coverage, the description is quite complete. It covers the flow, parameter roles, and return of a question. An output schema exists, so return value details are likely covered elsewhere. Minor omission: no mention of error handling or final result format, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully. It explains each parameter: 'step' for current step, 'value' for user answer, 'device' only needed at the device step. Example calls illustrate usage. This adds deep semantic context beyond the bare schema.
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 defines the tool as a guided power estimation wizard that collects parameters step by step. It uses the verb '引导式功耗评估向导' and distinguishes itself from siblings by its interactive step-by-step nature. The example flow further clarifies its purpose.
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 explicitly states that each call returns the next question for the user and that the AI agent must present questions and collect answers. It provides a typical flow and parameter explanations. However, it does not explicitly mention when not to use this tool or compare it to alternatives like 'estimate' or 'power'.
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?
No annotations provided, so description carries full burden. It details that 'start' launches a headless subprocess, 'stop' closes a session, and 'list' shows active sessions. It also explains modes ('py' vs 'gui' not implemented) and that each session_id corresponds to an independent instance. Could clarify if 'stop' is reversible.
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?
Description is well-structured with a title, bullet points for actions, and a parameter list. Front-loaded with the tool's purpose. Slightly verbose but every sentence adds value. Could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, output schema present), the description is complete: covers all actions, parameters, modes, and behavioral details. No gaps in information needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It thoroughly explains all five parameters: action, session_id, mode, pdm_path, timeout, including defaults and applicability conditions. Adds significant meaning beyond the bare schema.
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?
Description clearly states 'PDM session management (three-in-one tool)' and enumerates three actions (start, stop, list) with specific verbs and resources. It distinguishes itself from sibling tools by focusing on session management.
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?
Description explains when to use each action (start/stop/list) and mentions multi-session parallelism. However, it lacks explicit guidance on when not to use the tool or alternatives relative to siblings.
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:

[![PDM_MCP MCP server](https://glama.ai/mcp/servers/Can-Y/PDM_MCP/badges/card.svg)](https://glama.ai/mcp/servers/Can-Y/PDM_MCP)

Score Badge

Copy to your README.md:

[![PDM_MCP MCP server](https://glama.ai/mcp/servers/Can-Y/PDM_MCP/badges/score.svg)](https://glama.ai/mcp/servers/Can-Y/PDM_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/Can-Y/PDM_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server