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., "@PM-Copilot MCP Generate a PRD for a mobile checkout feature"
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.
An AI-powered Product Management Operating System exposed as a Model Context Protocol server. It gives Product Managers, founders, and product leaders a set of tools, prompts, and reference resources for the workflows they do every day — PRDs, user stories, prioritization, competitor analysis, roadmaps, KPIs, meeting notes, and product strategy — directly from Claude Desktop, Claude Code, Cursor, Windsurf, or any other MCP-compatible client.
PM-Copilot does not call out to an LLM API itself. Tools that produce narrative documents (PRDs,
user stories, competitor analysis, roadmaps, KPIs, meeting summaries, strategy docs) use the MCP
sampling capability to ask the connected client's own model to do the writing, using a
PM-best-practices system prompt and a structured request. prioritize_features is fully
deterministic: it computes RICE and ICE scores and MoSCoW buckets in code.
Related MCP server: Tycana
Tool | Purpose |
| Enterprise-grade Product Requirement Document |
| INVEST-compliant user stories with acceptance criteria and edge cases |
| RICE / ICE / MoSCoW scoring and final prioritization |
| Feature comparison matrix, SWOT, and strategic recommendations |
| Quarterly roadmap with milestones, dependencies, risks |
| North Star metric with leading/lagging indicators |
| Summary, decisions, risks, action items, follow-ups |
| Vision, mission, goals, market analysis, positioning, growth plan |
pm-copilot://templates/{prd,roadmap,user-story,strategy} — reusable document templates
pm-copilot://frameworks — reference definitions for RICE, ICE, MoSCoW, Kano, JTBD,
Opportunity Solution Tree, SWOT, Porter's Five Forces, and PESTLE
create_prd, generate_user_stories_prompt, analyze_competitor, build_product_strategy,
create_quarterly_roadmap — each wraps the corresponding tool with the right arguments.
src/
tools/ one module per MCP tool
resources/ templates + framework library, registered as MCP resources
prompts/ guided prompt wrappers around the tools
schemas/ Zod input schemas and shared validation helpers
utils/ structured logger and the sampling helper
server.ts builds and wires the McpServer
cli.ts stdio entrypoint (`pm-copilot-mcp` binary)
tests/ Jest unit testsnpm install
npm run build # compile TypeScript to dist/
npm test # run the Jest test suite
npm run start # run the compiled server over stdiodocker build -t pm-copilot-mcp .
docker run -i pm-copilot-mcpThe server communicates over stdio (the standard MCP transport for desktop clients), so run the
container interactively (-i) rather than publishing a port.
{
"mcpServers": {
"pm-copilot": {
"command": "node",
"args": ["/path/to/pm-copilot-mcp/dist/cli.js"]
}
}
}All tool inputs are validated with Zod; invalid input raises a descriptive error before any generation happens.
Structured JSON logs are written to stderr so they never collide with MCP JSON-RPC traffic on stdout.
Tool results return both human-readable text and structuredContent for programmatic clients.
Planned premium features include PM intelligence (usage/retention analytics), Jira/Notion/Linear integrations, and an AI product coach for interview and case-study practice — see the original product brief for the full commercialization plan.
Extract a summary, decisions, risks, action items, and follow-ups from meeting notes.
| Name | Required | Description | Default |
|---|---|---|---|
| meeting_notes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions extraction of specific items but does not cover limitations, required permissions, or side effects. The description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly lists five extraction types without any unnecessary words. It is efficiently 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?
For a tool with one parameter and no output schema, the description fails to explain what the tool returns or how the outputs are structured. This leaves the agent uncertain about the format of the extracted items.
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 schema has one required string parameter 'meeting_notes' with minLength: 1. The description adds no information about the parameter beyond what the schema provides, such as expected format or content type.
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 'Extract' and the resource 'meeting notes', listing specific outputs: summary, decisions, risks, action items, and follow-ups. This distinguishes it from sibling tools like competitor_analysis or generate_prd.
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, nor any context about prerequisites or exclusions. The description only states what it does without usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze competitors and identify strategic opportunities using a SWOT-style breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| product_name | Yes | ||
| competitors | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'analyze', which suggests a read operation but doesn't explicitly state behavioral traits like mutability, authentication needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and minimal parameter explanation, the description lacks details on the analysis output format, prerequisites, or how to interpret results.
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 adds no meaning to the parameters 'product_name' or 'competitors', leaving them ambiguous (e.g., what is the user's product? what constitutes a competitor?).
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 ('Analyze'), the resource ('competitors'), and the approach ('SWOT-style breakdown'). It distinguishes from siblings like 'generate_strategy' by specifying SWOT, but could be more precise about the output.
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. The purpose implies competitor analysis, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a KPI framework with a North Star Metric, leading/lagging indicators, and dashboards.
| Name | Required | Description | Default |
|---|---|---|---|
| product_type | Yes | ||
| goal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects, permissions, rate limits, or return format. For a generative tool, it lacks transparency on what the output contains beyond the listed components.
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 with no wasted words. However, it omits necessary details, making it efficient but not fully informative.
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 lack of output schema, annotations, and parameter descriptions, the description is inadequate. It does not cover what the agent needs to know to use the tool correctly in different contexts.
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%, but the description does not explain the parameters product_type and goal. The agent must infer their meaning from names alone, which is insufficient for correct invocation.
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 generates a KPI framework including North Star Metric, leading/lagging indicators, and dashboards. However, it does not differentiate from sibling tools like generate_strategy, which may also involve KPIs. The verb 'generate' and resource 'KPI framework' are specific.
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 siblings such as generate_strategy or generate_prd. The agent receives no context for appropriate usage or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an enterprise-grade Product Requirement Document from a feature idea.
| Name | Required | Description | Default |
|---|---|---|---|
| product_name | Yes | ||
| feature_name | Yes | ||
| problem_statement | Yes | ||
| target_users | Yes | ||
| business_goal | Yes |
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 fails to mention output format, length, quality expectations, or any limitations. The vague term 'enterprise-grade' does not meaningfully convey behavior beyond the basic action.
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 with no redundancy. It is appropriately sized for a straightforward tool, though it could benefit from additional detail 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 five required parameters, no output schema, and no annotations, the description is insufficient. It does not explain what the generated PRD contains, how it is structured, or any contextual dependencies, leaving significant gaps for an agent relying solely on this description.
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 input schema has 0% description coverage, meaning parameters lack any textual explanation. The description only mentions 'feature idea' but does not clarify the five required parameters (product_name, feature_name, etc.) or their roles, leaving the agent to infer from parameter 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 creates a Product Requirement Document from a feature idea, using a specific verb and resource. However, it does not differentiate from sibling tools like generate_user_stories or generate_roadmap, which could lead to confusion about which tool to use for related tasks.
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 vs. alternatives. There is no mention of prerequisites, exclusions, or context that would help an agent decide between generate_prd and sibling tools like competitor_analysis or prioritize_features.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a quarterly roadmap with milestones, dependencies, risks, and success indicators.
| Name | Required | Description | Default |
|---|---|---|---|
| product_vision | Yes | ||
| features | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only lists output components. It does not indicate whether the tool overwrites existing data, requires specific permissions, or has constraints on input size.
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, making it concise, but it sacrifices important detail. It could be slightly longer to cover parameter roles without being 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 no output schema, no annotations, and high parameter count (2 required), the description should provide more context on return format, expected inputs, and edge cases. It falls short.
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% and the description does not explain the meaning or format of 'product_vision' or 'features'. The agent cannot infer what values are acceptable or how they influence the generated roadmap.
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 quarterly roadmap and lists key components (milestones, dependencies, risks, success indicators), distinguishing it from sibling tools like generate_prd or competitor_analysis.
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. It does not specify prerequisites, desired inputs, or situations where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a product strategy document: vision, mission, goals, market analysis, positioning, growth plan.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| product | Yes | ||
| business_goal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool generates a document but fails to mention safety (e.g., idempotent?), authentication needs, or any side effects. Minimal behavioral 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?
Single sentence that front-loads the core purpose and lists components. While efficient, it could be slightly more structured (e.g., bullet list) but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generation tool with 3 required parameters and no output schema, the description omits crucial details about input semantics, output format, and behavioral expectations. It is incomplete for safe and correct 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 coverage is 0% and the description does not describe any of the three parameters (market, product, business_goal). The description only lists output components, leaving agent to guess input meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a product strategy document listing key components (vision, mission, goals, market analysis, positioning, growth plan). It distinguishes itself from sibling tools like competitor_analysis (focuses only on competition) and generate_prd (product requirements document).
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. No context about prerequisites, typical use cases, or when not to use it is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate INVEST-compliant agile user stories with acceptance criteria and edge cases.
| Name | Required | Description | Default |
|---|---|---|---|
| feature_description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It mentions INVEST-compliance and inclusion of acceptance criteria and edge cases, but omits details like input limitations, output format, or whether it handles ambiguous descriptions.
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 with 9 words, very concise and front-loaded. However, it sacrifices necessary information for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about the output (e.g., number of stories, format) and any constraints. It 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%, yet the description adds no details about the 'feature_description' parameter beyond the schema's type and minLength. It does not explain expected format, length, or examples.
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 generates INVEST-compliant agile user stories with acceptance criteria and edge cases, using a specific verb and resource. However, it doesn't explicitly distinguish from sibling tools like generate_prd, which also generate requirements.
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 such as generate_prd or competitor_analysis. It only implicitly indicates its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank features using RICE, ICE, and MoSCoW frameworks. Accepts plain feature names or objects with reach/impact/confidence/effort/ease to refine the scoring; missing fields use sensible defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| features | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that missing fields use sensible defaults, but does not disclose output format, side effects, or prerequisites. Partial transparency is achieved.
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 two sentences, efficient, and front-loaded with key information. Every word contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and absence of an output schema, the description is missing an explicit statement about what the tool returns (e.g., ranked list). It is adequate but not complete.
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. It explains that features can be strings or objects with specific numeric fields (reach, impact, etc.) and that defaults are used, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool ranks features using RICE, ICE, and MoSCoW frameworks. It specifies input formats (plain names or objects) and distinguishes itself from sibling tools that focus on other tasks like analysis or generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for prioritization, but does not explicitly state when to use versus alternatives or provide exclusion criteria. However, the context is clear and the tool's purpose is specific enough to guide appropriate use.
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 product management task: meeting analysis, competitor analysis, KPI generation, PRD creation, roadmap, strategy, user stories, and prioritization. There is no functional overlap.
Most tools follow a verb_noun pattern (generate_*, analyze_meeting_notes, prioritize_features), but 'competitor_analysis' deviates to noun_noun. Overall consistent and readable.
With 8 tools, the set is well-scoped for a product management assistant, covering essential planning and analysis tasks without unnecessary bloat.
The tools cover core planning and analysis functions (PRD, roadmap, strategy, user stories, prioritization, KPIs, competitor analysis). Missing operational features like tracking or updating items, but comprehensive for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered product management: backlog optimization, scheduling, forecasting, and PRD generation.
Your product team's shared strategic memory — an MCP server your AI tools reason over.
Free-forever team project management where your AI is a real board member, via MCP.
AIOProductOS: revenue, feedback, work and analytics on one customer record. 71 tools, 3 apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sumukhmg/Mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
