Primer MCP server

Read from the package source without running it. The installed server may list more.

• complete_spike

  Close a spike by recording its findings — the answer to the question it was investigating and any recommendations. Works from any status.

• complete_task

  Mark a task as completed with notes on what was done. The notes parameter is a terse one-liner for the frontmatter field; write a fuller summary (approach, key changes, decisions) into the ## Completion Notes body section of the ticket separately. Ideally call start_task first, but this works from any status. After this, call verify_task with evidence to finalise.

• create_spikewrite action

  Create a Spike under a story — a timeboxed investigation to answer a specific question before committing to an implementation approach. The parent story must already exist. When done, call complete_spike with your findings.

• create_storywrite action

  Create a Story under an epic — a deliverable with acceptance criteria. The epic must exist — if one hasn't been created yet, call plan_epic first. The user will have described their goals; use that to create the epic, asking for clarification if needed. If no ADR has been recorded, the response will suggest capturing decisions first, but the story is still created.

• create_taskwrite action

  Create a Task under a story — a concrete unit of implementation work with a testable outcome. The parent story must already exist.

• delete_ticketwrite action

  Delete a ticket. Non-todo tickets are deleted with a warning. Children are reported but not deleted — call delete_ticket on each to cascade. After all deletions, call sweep_blocked_by to clean up dangling references. Recoverable from git history.

• export_graph

  Generate a self-contained HTML file visualising the project as an interactive graph. Opens in any browser with no external requests. Nodes are coloured by type and status; edges show both hierarchy (epic -> story -> task) and dependencies (blocked_by). Click a node to see its details. On-demand — call when you want a snapshot.

• get_ticket

  Read one ticket by ID, with its full body. Also reports which tickets it blocks — that direction is not stored on the ticket itself, so this is the only way to see it.

• init_project

  Initialise this project for primer-mcp: creates the primer/ ticket store and adds the workflow section to CLAUDE.md and AGENTS.md, creating them if needed. Non-destructive and idempotent. Call this once per project, before any other tool. Optionally pass jira_project_key if tickets may later be exported to Jira.

• list_actionable

  List what can be acted on right now, with epic context.

• list_tickets

  List tickets one per line, newest work last. Filter by type (epic, adr, story, task, spike), status, or parent_id (show only children of that ticket). Use this to find an ID before calling another tool.

• plan_epicwrite action

  Create an Epic — the top-level container for a body of work. Start here: state why the work matters, its goals, and how you'll know it's done. Consider recording decisions (record_adr) before creating stories — it captures reasoning that gets lost once implementation starts.

• record_adr

  Record an Architecture Decision Record under an epic: the context forcing a choice, the decision, alternatives rejected (with reasons), and consequences accepted. Recording decisions before creating stories is recommended — it captures reasoning that gets lost once implementation starts.

• start_task

  Transition a task to in-progress — call this when you begin working on a task. Works from any status; you'll get a note if the transition is unusual. After finishing, call complete_task.

• sweep_blocked_bywrite action

  Remove blocked_by references that point to tickets that no longer exist. Call once after finishing a batch of delete_ticket calls.

• update_ticketwrite action

  Amend a ticket after creation; anything left out is left alone.

• verify_task

  Verify a task with evidence that the work holds (e.g. "218 passed, mypy clean"). Pass the short commit hash in the commit parameter so it is labelled consistently. Ideally call complete_task first to capture notes, but this works from any status. Sets the task to verified.

• Code scan16 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 32 days ago12/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

88/100

higher than 75% of 1,119 Developer tools servers

Tools

17

the typical Developer tools server has 7

Tools that change things

41%

typical: 5%. Fewer write tools means less an agent can break

Downloads a week

60

more than 44% of 436 Developer tools servers with a package

Primer: common questions

Is Primer MCP server safe?

Yes, by our scan: it is graded A (88/100). Read the Primer safety report

How do I install Primer?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Primer need an API key?

Not as far as the registry entry and our scan can tell: no credentials are declared or required.

Is Primer maintained?

The last commit was 33 days ago (2026-10-01). The latest release is v0.1.8.

What can I use instead of Primer?

Servers from other publishers that do the same job: Agent Harnesses MCP server, Atlassian Dc Jira MCP server and Atlassian Rovo MCP Server.

How does Primer compare with other Developer tools MCP servers?

safety score 88/100 (higher than 75% of 1,119 Developer tools servers); tools 17 (the typical Developer tools server has 7); tools that change things 41% (typical: 5%. Fewer write tools means less an agent can break). Full comparison.