Provides an issue tracker exporter that automatically syncs generated product backlog items with GitHub Issues.
Provides an issue tracker exporter that automatically syncs generated product backlog items with Jira issues.
Provides an issue tracker exporter that automatically syncs generated product backlog items with Linear issues.
Click on "Deploy 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., "@PMFlow MCP generate a PRD for Apple Pay checkout with measurable KPIs"
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.
Autonomous Product Management Workflow, PRD Engine & BDD Story Validator for AI Agents
PMFlow MCP gives AI agents (Claude Desktop, Cursor, Devin, Roo-Code) the capabilities of a Senior Technical Product Manager. It generates structured Product Requirement Documents (PRDs), decomposes epics into testable User Stories, validates Given/When/Then acceptance criteria for testability, and exports markdown backlogs.
Automated PRD Generator (generate_prd): Creates complete PRD specifications with MoSCoW prioritization, functional requirements, technical constraints, risks, and measurable KPIs.
Atomic Story Decomposer (decompose_stories): Formats requirements into standard agile format: "As a [persona], I want [goal], so that [benefit]" with estimated story points.
BDD/Gherkin Syntax Validator (validate_acceptance_criteria): Enforces Given/When/Then syntax, flags ambiguous terms (e.g., "fast", "intuitive", "easy") that cause agent drift, and calculates a 0-100 testability score.
Markdown Specification Exporter (export_markdown_specs): Generates clean, commit-ready documentation for repositories.
Related MCP server: Agile Planner MCP Server
git clone https://github.com/johannschiffer/pmflow-mcp.git
cd pmflow-mcp
pip install -e .Add to your claude_desktop_config.json:
{
"mcpServers": {
"pmflow": {
"command": "python3",
"args": ["-m", "pmflow.server"]
}
}
}# Generate a PRD in Markdown
pmflow prd \
--title "Payment Gateway Integration" \
--problem "Customers cannot check out with Apple Pay" \
--audience "Mobile checkout shoppers" \
--features "Stripe SDK setup" "Apple Pay button" "Webhook listener" \
--markdown
# Validate BDD Acceptance Criteria
pmflow validate --criteria \
"Given user is on checkout page" \
"When user taps Apple Pay button" \
"Then payment sheet opens within 300ms"Need enterprise capabilities for multi-agent swarms? Check out PMFlow Pro:
User Story Dependency DAG Engine: Cycle detection via Kahn's algorithm and critical path calculation in SQLite WAL.
Sprint Velocity & Capacity Forecaster: Monte Carlo simulation of agent capacity and bottleneck alerts.
Issue Tracker Exporter: Automatic sync with Jira, Linear, and GitHub Issues.
Docker Compose: Production containerization ready for agent clusters.
Available at Gumroad.
MIT © Johann Schiffer
Decomposes a requirement into an atomic User Story with BDD Given/When/Then acceptance criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | Action the user wants to take | |
| title | Yes | Short title of the user story | |
| benefit | Yes | Underlying business or technical value | |
| persona | Yes | User role (e.g., DevOps Engineer) | |
| story_id | Yes | Unique identifier (e.g. US-001) | |
| depends_on | No | List of parent story IDs | |
| story_points | No | Estimated complexity points (default 3) | |
| acceptance_criteria | Yes | List of Gherkin steps (Given/When/Then) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden of behavioral disclosure, yet it only says what is produced. It does not say whether anything is persisted, whether the call is idempotent, whether output is returned inline or written to a file, or whether it mutates existing stories. For a 6-required-parameter generation tool with zero annotation coverage, that is a significant gap.
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?
A single front-loaded sentence with no filler, and the key output characteristic (atomic story with BDD criteria) is stated up front. It is efficient, though its brevity is partly a symptom of under-specification rather than deliberate economy.
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 transformation/generation tool with 8 parameters, no annotations, and no output schema, the description omits prerequisites, side effects, and what the caller receives back. An agent cannot tell from this text whether the tool writes a ticket, returns JSON, or requires a prior PRD step.
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 100%, so all 8 parameters are already documented in the schema, establishing a baseline of 3. The description only adds the notions 'atomic' and 'BDD Given/When/Then acceptance criteria', which loosely maps to the acceptance_criteria field but gives no new syntax or constraint detail.
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?
States a specific verb (decomposes) and resource (a requirement into an atomic User Story) and even names the output artifact's format (BDD Given/When/Then criteria). It does not, however, differentiate itself from siblings like generate_prd or validate_acceptance_criteria, which an agent could easily confuse with this one.
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?
There is no when-to-use, when-not-to-use, or prerequisite guidance. The description never says whether a PRD or requirement document must exist first, nor why an agent would pick this over validate_acceptance_criteria or generate_prd.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exports structured PRD and story backlog into standardized Markdown documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| prd | No | Optional PRD dict generated by generate_prd | |
| stories | No | Optional list of story dicts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the output format (Markdown) but does not say whether it writes a file, returns content, overwrites existing documentation, requires permissions, or how errors are handled.
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?
A single front-loaded sentence with no filler; every phrase contributes to stating the action and output format.
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?
With no annotations and no output schema, the one-sentence description does not explain the return value, destination, or side effects of exporting. For a tool with nested optional objects, it leaves too much unspecified for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both optional parameters. The description broadly maps 'PRD and story backlog' to prd/stories but adds no extra meaning about optionality or what happens when either parameter is omitted, so the baseline of 3 applies.
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?
States a specific verb ('Exports') and resources ('structured PRD and story backlog') plus the output format ('standardized Markdown documentation'). It is distinguishable from siblings such as generate_prd and decompose_stories because it exports rather than generates, though it does not explicitly name alternatives.
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 gives no when-to-use, when-not-to-use, or alternative guidance. The only hint is in the schema descriptions noting that prd may come from generate_prd, but that does not guide invocation choices or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a structured, production-ready PRD with requirements, tech stack, constraints, and success metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the product or feature | |
| key_features | Yes | List of core features | |
| success_metrics | No | Optional measurable KPIs | |
| target_audience | Yes | Target personas and user profiles | |
| technical_stack | No | Optional list of technologies | |
| problem_statement | Yes | Core problem being solved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses what the artifact contains but not whether generation is deterministic or LLM-backed, whether the PRD is persisted or merely returned, or what the caller should do with it next — meaningful gaps for a generation tool.
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?
A single tight sentence with the outcome front-loaded; no filler or restatement of the tool name. Slightly dense with the enumerated contents, but every clause is 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?
With no annotations and no output schema, the description should at minimum say what form the generated PRD takes and how it feeds the sibling tools. It conveys the artifact's sections but leaves the return value and downstream workflow unstated — adequate but with clear gaps.
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 100%, so all six parameters are already documented. The description's list of contents loosely maps to key_features, technical_stack, and success_metrics, but it introduces 'constraints', which is not an input parameter, and adds no input-formatting detail beyond the schema. Baseline 3 applies.
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?
States a specific verb (Generates) and resource (PRD), and enumerates the artifact's contents: requirements, tech stack, constraints, success metrics. Clear on its own, but it never distinguishes itself from siblings like decompose_stories or export_markdown_specs, which operate on the same PRD artifact.
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 when-to-use guidance, no prerequisites, and no mention of the other tools in the workflow. An agent must infer from the name alone that this is the first step before decompose_stories, validate_acceptance_criteria, or export_markdown_specs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates acceptance criteria syntax (Given/When/Then) and flags non-testable or ambiguous language.
| Name | Required | Description | Default |
|---|---|---|---|
| criteria | Yes | List of BDD/Gherkin scenario statements |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses real behavior (syntax checking plus flagging non-testable/ambiguous language), which implies a safe read-only operation, but never states that it is non-mutating, requires nothing else, or how results/errors are reported.
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?
One tight sentence, front-loaded with the primary action. Nothing is redundant or padded.
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 simple single-parameter tool this is adequate on the input side, but with no output schema and no annotations the description leaves the return shape (pass/fail vs. list of flags) and the criteria for 'non-testable' undefined, which an agent would want to know.
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 100% for the single 'criteria' array parameter ('List of BDD/Gherkin scenario statements'), so the schema already documents it. The description adds only the Given/When/Then format expectation, which is marginal beyond the schema's BDD/Gherkin wording.
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?
States a specific verb (validates) and resource (acceptance criteria syntax in Given/When/Then form), plus a secondary action (flags non-testable/ambiguous language). This clearly distinguishes it from the generative/export siblings, though it never names them explicitly.
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 when-to-use guidance, prerequisites, or alternatives are given. It does not say whether this should be run before or after decompose_stories/generate_prd, or what to do with the flags it produces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0decompose_storiesexport_markdown_specsgenerate_prdvalidate_acceptance_criteriaScored across 4 tools
Each tool targets a distinct artifact and action in the pipeline: PRD generation, story decomposition, criteria validation, and markdown export. There is no meaningful overlap, so an agent can select the right tool unambiguously.
All four tools follow a consistent snake_case verb_noun pattern (generate_prd, decompose_stories, validate_acceptance_criteria, export_markdown_specs). The convention is uniform and predictable.
Four tools map cleanly onto the generate-decompose-validate-export pipeline, which is well-scoped rather than bloated. It is slightly thin, but each tool clearly earns its place.
The core generation pipeline is covered, but there are no read/update/delete operations, so an agent cannot retrieve, revise, or list existing PRDs and stories. This is a notable gap for a document-authoring workflow.
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
Generate architecture docs, implementation plans, and dev tickets from your project requirements.
Tasks, sprints, releases and docs for engineering teams with AI coding agents.
Your team's stories, acceptance criteria, designs and docs, for coding agents. Sign in with OAuth.
