Cpm Planner vs MCP Jira Stdio
A side-by-side look at the Cpm Planner and MCP Jira Stdio MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Cpm Planner for product management work as a local process; choose MCP Jira Stdio for product management as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Cpm Planner when
- You need dedicated capabilities in the Product Management domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You have the keys it needs:
CPM_PLANNER_DB. - You want tools like
plan.release.compile, plan.release.diff, plan.submit.
Choose MCP Jira Stdio when
- You need dedicated capabilities in the Product Management domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: API key required.
- You have the keys it needs:
JIRA_BASE_URL, JIRA_EMAIL, JIRA_API_TOKEN. - You want tools like
jira_get_visible_projects, jira_get_issue, jira_search_issues.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Product Management | Product Management |
| Quality signal | 63/100 · Good | 67/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | No auth required | API key required |
| Pricing | Free | Not declared |
| Required env vars | CPM_PLANNER_DB | JIRA_BASE_URLJIRA_EMAILJIRA_API_TOKEN |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 14 |
| Directory activity | 0 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 25 | 23 |
| Full listing | View Cpm Planner | View MCP Jira Stdio |
Tools & capabilities
Cpm Planner tools 25
plan.release.compileCompile version-1 bounded release metadata into an ordinary lint-clean PlanGraph. Expands protected PR/check/approval/merge hops, producer retries, retained receipts and central acceptance. Every collection declares cardinality or a bounded retained source. Pure offline operation: never executes, accepts, submits or baselines work.plan.release.diffCompare a retained compiled graph with current version-1 workflow/promotion policy. Reports policy_changed, added/removed/changed ids and stale; includes retained-history estimate drift. Read-only: apply accepted changes through normal plan.sync or plan.revise.plan.submitSubmit a plan graph and receive a plan_id. Idempotent: identical graphs return the same plan_id. With `name` (and optional `project`/`variant`, variant defaults to "main"), registers a named variant instead: project defaults to the discovered project root.plan.acquire_cohortAcquire up to max_count ready deliverables with no conflicting file claims atomically. Returns the cohort plus per-deliverable locks. A deliverable explicitly marked failed 3 times is circuit-broken to failed instead of re-leased; leases lost environmentally (TTL lapse, no terminal mark) never trip that breaker but are bounded separately (LAPSE_LIMIT at 10). Optional ttl_seconds sets the lease TTL (clamped to the server maximum). Optional ids targets specific deliverables and filter.metadata narrows by metadata equality; deliverables with metadata.kind = "manual" are never leased. ids that do not match filter.metadata are ignored (not reported in blocked). The response carries blocked [{id, code, reason}], blocked_count, and needs_operator (true when any blocked code is LAPSE_LIMIT: clear with plan.force_release {reset_counters: true}). Select the plan by plan_id, plan line name, or active: true.plan.heartbeatRefresh the TTL on a held lock; LOCK_NOT_HELD or LOCK_EXPIRED on failure. Optional ttl_seconds sets the new TTL (clamped to the server maximum); without it the lease is never shortened. Select the plan by plan_id, plan line name, or active: true.plan.mark_statusSet a deliverable's status. Complete/Failed releases the lock; caller_id mismatch yields LOCK_NOT_HELD. Without a lock, Complete, Ready or InProgress requires all prerequisites complete (PREREQUISITES_INCOMPLETE) and is audited; other lockless marks are audited too, and an already-complete deliverable cannot be changed (LOCK_NOT_HELD). A lockless in_progress persists across restarts and is not leasable; hand it back with a lockless ready (or other status) mark. plan.force_release does not affect it. Optional earned-value progress: earned_pct (0..100, only with in_progress; ignored with complete), actual_effort_hours (total so far, 0..1000000; replaces leased hours as actual cost) and evidence (<= 2048 chars, appended to a list of at most 100); violations are INVALID_ACTUALS. Every lease that ends adds its hours to the deliverable's leased hours. Select the plan by plan_id, plan line name, or active: true.plan.statusRead-only snapshot: per-deliverable [id, status, attempt_count, failure_count, lapse_count] rows, critical_path (one real chain, always from __start__ to __finish__), critical_ids, per-deliverable schedule (es/ef/ls/lf/float, hours; synthetic __start__/__finish__ rows have synthetic=true), the ready set in float-ascending order (smallest float first, then smallest latest start, then id), plan_complete, milestones (per milestone: id, critical_path from __start__, hours, complete), and held locks. Select the plan by plan_id, plan line name, or active: true.plan.getReturn the stored PlanGraph (deliverables, estimates, files, metadata) for a plan selected by plan_id, plan line name, or active: true.plan.force_releaseOperator escape hatch — release a lock regardless of caller. Emits an audit event carrying `reason`. Select the plan by plan_id, plan line name, or active: true.plan.acceptManager/owner acceptance: mark a deliverable Complete without holding its lease. Requires all prerequisites Complete and evidence; audited. A live lease held by someone else is refused (LOCK_HELD) unless override_lock is true. Select the plan by plan_id, plan line name, or active: true.plan.lintLint a graph, stored plan, or plan file without creating one: cycles (with the loop), redundant edges, edges without rationale, interface edges not targeting a contract, deliverables feeding no milestone, and unordered file overlaps. Linting by plan_id also adds NO_BASELINE (warning) when the plan is executable and has recorded progress but no earned-value baseline. Provide exactly one of graph, plan_id, or path.plan.scheduleLevel a graph or stored plan against resource capacities (`metadata.owner` by default; metadata.resources can claim several pools concurrently): makespan, per-deliverable start/finish, per-resource load, the driving chain (dependency vs named resource waits), and project/feeding buffers. A deliverable with duration_hours plus metadata.wall_clock_only:true advances elapsed time but consumes no capacity. Provide exactly one of graph or plan_id. capacities is required: every resource that carries work needs at least 1 unit (otherwise INVALID_CAPACITIES: lists the missing resources). plan.schedule rejects what plan.submit rejects (INVALID_GRAPH:).- +13 more on the listing page
MCP Jira Stdio tools 23
jira_get_visible_projectsRetrieves all projects accessible to the authenticated user. Returns project keys, names, descriptions, and basic metadata.jira_get_issueRetrieve details for a specific Jira issue by key or URL. Use this when the user mentions an issue like "PAYWALL-943" or pastes a Jira link (e.g., https://your.atlassian.net/browse/PAYWALL-943). Returns status, assignee, priority, project, type, labels, components, timestamps, and description.jira_search_issuesSearch for Jira issues using JQL. Supports complex queries with pagination and field selection. Examples: "project = PROJECT AND status = Open", "assignee = currentUser()". For pagination, use nextPageToken from previous response.jira_get_my_issuesRetrieves issues assigned to current user, sorted by most recently updated first. Supports pagination and field selection. For pagination, use nextPageToken from previous response.jira_get_issue_typesRetrieves available issue types. Can get global issue types or project-specific issue types including regular issues and subtasks (Bug, Story, Task, Epic, etc.).jira_get_usersSearch for users by name, email, username, or account ID. Returns display name, email, account status, and account type. Supports pagination.jira_get_prioritiesRetrieves available priorities (e.g., Highest, High, Medium, Low, Lowest). Returns IDs, names, and descriptions.jira_get_statusesRetrieves available statuses (global or project-specific, e.g., To Do, In Progress, Done). Returns status categories and workflow information.jira_get_project_infoRetrieves detailed information about a project (components, versions, issue types, roles, insights). More comprehensive than the basic project list.jira_get_create_metaRetrieves create metadata for a project, showing all available fields (including custom fields) for creating issues. Shows required vs optional fields, field types, and allowed values. Use this before creating issues to discover what fields are needed.jira_get_custom_fieldsRetrieves all custom fields available in Jira. Shows custom field names, IDs (e.g., customfield_10071), and types. Useful for discovering what custom fields exist and their identifiers.jira_get_commentsRetrieves all comments for a Jira issue. Returns comment author, content, timestamps, and visibility settings. Supports pagination for issues with many comments.- +11 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Cpm Planner
{
"mcpServers": {
"cpm-planner": {
"command": "npx",
"args": [
"-y",
"@matthew-cochran/cpm"
],
"env": {
"CPM_PLANNER_DB": "YOUR_CPM_PLANNER_DB_HERE"
}
}
}
}
MCP Jira Stdio
{
"mcpServers": {
"mcp-jira-stdio": {
"command": "npx",
"args": [
"-y",
"mcp-jira-stdio@latest"
],
"env": {
"JIRA_BASE_URL": "YOUR_JIRA_BASE_URL_HERE",
"JIRA_EMAIL": "YOUR_JIRA_EMAIL_HERE",
"JIRA_API_TOKEN": "YOUR_JIRA_API_TOKEN_HERE"
}
}
}
}
Frequently asked questions
Cpm Planner is categorized under Product Management and uses a local stdio subprocess. MCP Jira Stdio belongs to Product Management and uses a local stdio subprocess. Pick Cpm Planner for product management work and MCP Jira Stdio for product management.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Cpm Planner is listed as free. Auth: no auth required. MCP Jira Stdio has no declared pricing — check the project's own site. Auth: api key required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add cpm-planner and mcp-jira-stdio as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Cpm Planner has a quality signal of 63/100 (Good) with 0 views, 0 installs and 0 GitHub stars. MCP Jira Stdio has 67/100 (Great) with 2 views, 0 installs and 14 GitHub stars.