Story Mapper MCP server

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

• attachment_deletewrite action

  Delete a binary attachment by id. Returns {deleted: id|null}.

• attachment_get

  Read a binary attachment. ALWAYS returns metadata + a downloadUrl (the REST

• attachment_list

  List binary attachments (metadata only — no content) of a project. Pass ticketId

• attachment_putwrite action

  Upload a binary attachment (base64) to a project. OMIT ticketId for a

• bulk_change_status

  Change the status of multiple tickets in one revision. Each ticket

• bulk_link_createwrite action

  Create the same-typed link from each ticket in sourceTicketIds[] to

• bulk_ticket_updatewrite action

  Apply the same `patch` to multiple tickets in one revision. Per-item:

• cancel_ticketwrite action

  Cancel a ticket — record a deliberate non-implementation (scope reduction), gate-free. Cancel ≠ Delete: cancel keeps the ticket VISIBLE with its full history + links (use ticket_delete only for mistakes). Cancelling an EPIC cascades: every contained non-terminal story is cancelled in one revision and the epic rolls up to cancelled (or done, if some stories had already shipped). Cancelled tickets d

• change_ticket_status

  Change a ticket's status. Forward transitions crossing → ready check DoR; crossing → done check DoD. A transition INTO the done category ALSO fires the complete_ticket governance gates (SM-299: MISSING_TEST_DEFINITION for user-story/bug, STALE_LINKED_DEF, OPEN_MODIFIES) — there is no bypass around complete_ticket. Failures come back as isError with kind/missing. NOT applicable to epics — an epic's

• complete_ticket
• derive_test_definition

  SM-301: derive a test-definition from a ticket's ACCEPTANCE CRITERIA — one step per AC (step = the criterion, expectedResult = its observable outcome), linked back via a `tests`-link. The acceptance criteria ARE the test plan: set them first, then call this immediately as the north-star plan (refine steps during implementation). Draft by default; pass publish:true to also publish (the target must

• export_project

  Export a whole project as the re-importable storymap-project JSON envelope

• generate_product_doc

  Generate a current-state product description (Markdown) by FOLDING the tickets

• get_config

  Read a project config section. section ∈ definitions | workflow |

• get_drift_report

  Round-trip / drift report (SM-182, direction-A Phase 4) — keeps the PRD a living

• get_revision

  Fetch a single revision (full snapshot at that point in time). Returns 404-error if the revision does not exist.

• get_trace_coverage

  Direction-A coverage report (mirror of generate_product_doc). For each requirement,

• import_tickets

  Bulk-import tickets from CSV (header row = field keys: key, type, title, description,

• ingest_slice_candidates

  Read a project attachment (a source PRD), convert it to Markdown server-side

• link_createwrite action

  Add a typed link from one ticket to another. linkTypeId references a project.linkTypes entry (predecessor-of / blocks / follows-on / contains / relates-to by default — get_link_types for the catalogue). Throws LINK_SELF for self-links, LINK_TARGET_MISSING for unknown target, LINK_DUPLICATE for duplicate (linkTypeId, targetTicketId), LINK_CYCLE if the new edge would close a cycle in a cycle-checked

• link_deletewrite action

  Remove a single link from a ticket by linkId. No-op if the linkId is not on the source ticket.

• list_links_for_ticket

  List links involving a ticket. direction: 'forward' = links this ticket owns; 'backward' = links from OTHER tickets pointing here (resolved via project.linkTypes.inverseLabel); 'both' (default) = combined. Each entry has linkTypeId, label (project-resolved or the link's stored label), direction, target { id, ticketKey, title, type }. Use this to power a Ticket-Detail-Modal's Links-section.

• list_process_steps

  List all non-deleted process steps of a project, sorted by sortOrder.

• list_projects

  List all (non-deleted) project IDs

• list_releases

  List all non-deleted releases of a project. Returns an array of release objects sorted by sortOrder.

• list_revisions

  List the revision history of a project (reverse-chrono). Returns up to `limit` entries (default 100); pass `before` (a revision id) to page older entries.

• list_tickets

  List non-deleted tickets of a project. Filters (all optional, AND-combined):

• mark_ready

  Shortcut for change_ticket_status → 'ready'. Fails with kind=DoR + missing[] if the DoR is not satisfied. NOT applicable to epics (kind=EPIC_STATUS_DERIVED) — epic status is derived from its stories. Compact response by default; pass verbose:true for the full ticket.

• next_actionable

  What can I start NOW? Returns the work-item tickets that are ready to pull:

• process_step_createwrite action

  Create a new process step (a column on the story-map backbone).

• process_step_deletewrite action

  Soft-delete a process step.

• process_step_updatewrite action

  Patch fields on a process step (name, description, epicId, sortOrder).

• project_createwrite action

  Create a new project. Optional fields: definitions (DoR/DoD), workflow (statuses + transitions + per-type overrides), entityTypeConfig (per-type modal config), ticketTypes (allowed type names).

• project_deletewrite action

  Soft-delete a project (filtered out of list_projects)

• project_get

  Load the full snapshot of a project

• project_updatewrite action

  Patch project header fields (name, description, ticketPrefix, definitions)

• publish_test_definitionwrite action

  Promote a test-definition from lifecycle='draft' to 'published'. Runs the SM-93 governance publish-gates: ≥1 step, ≥1 outgoing 'tests'-link, every step has expectedResult, target ticket has reached 'ready'+. On gate failure returns isError with kind/errors/message{title,reason,suggestion,skillRef}.

• query_tickets

  Targeted ticket search (SM-187) with a JQL-angelehnter query language — the precise

• release_createwrite action

  Create a new release on the project. Returns the created release plus revision/savedAt.

• release_deletewrite action

  Soft-delete a release (recoverable via history). Refuses the LAST remaining release (422 kind=LAST_RELEASE) — a project always keeps ≥1 release.

• release_updatewrite action

  Patch fields on a release (name, description, status, startDate, endDate, sortOrder).

• reopen_test_definition

  Revert a test-definition from lifecycle='published' to 'draft' so its spec can be edited again. Blocks with kind=ACTIVE_EXECUTION if any associated test-execution is currently in 'in-progress' — finish or cancel the run first.

• reorder

  Reorder entities by full id list. entity ∈ 'tickets' | 'releases' |

• request_switch_project

  Ask every connected browser to switch to the named project. The browser shows a confirm dialog; the tool waits up to wait_seconds (default 30) for the user's verdict and returns { requested, requestId, response:{accepted}, timedOut? }. Pass wait_seconds:0 for fire-and-forget. Use this AFTER preparing a project so the user lands on the right place and can verify your work.

• requirement_createwrite action

  Create a `requirement` SpecObject — one atomic, sliced PRD statement. Provide its

• requirement_list

  List requirement SpecObjects of a project, in document order (by sectionPath).

• resolve_definitions_for_ticket

  Return the EFFECTIVE DoR/DoD checklists for a ticket — i.e. the per-ticket frozen items with their current checked-state. Use this to see what's left to do for mark_ready / complete_ticket.

• restore_revision

  Restore a project to a previous revision. The restore creates a NEW revision with op='project_restore', so the restore itself is undoable.

• set_checklist_item

  Check or uncheck a single DoR/DoD item on a ticket. gate ∈ 'dor'|'dod'

• set_config

  Replace a project config section (full replace, no merge). section ∈

• spec_module_createwrite action

  Create a spec module — the container for the requirements sliced from ONE source

• split_process_step

  Split a process step (SM-247): create a NEW step directly after it and move the chosen epics (with their contained stories) into the new step. Loose stories stay with the original. epicIds must reference epics currently in this step (else 422 with `missing`). Empty/omitted epicIds inserts an empty step after the original. One revision.

• test_def_prereq_add

  Append a prerequisite to a test-definition. patch = { label: string, required?: boolean }. Default required=true.

• test_def_prereq_check

  Mark a prerequisite as checked.

• test_def_prereq_removewrite action

  Remove a prerequisite from a test-definition.

• test_def_prereq_uncheck

  Mark a prerequisite as unchecked.

• test_def_prereq_updatewrite action

  Update a prerequisite. patch = { label?, required? }.

• test_def_step_add

  Append a step to a test-definition. patch = { step: string, data?: string, expectedResult: string, position?: number }. Returns the created step.

• test_def_step_removewrite action

  Remove a step from a test-definition.

• test_def_step_reorder

  Reorder steps on a test-definition by full ID list. orderedStepIds is the new sequence; missing steps are appended at the end (defensive). Pass tolerated JSON-string for Claude Code MCP bridge.

• test_def_step_updatewrite action

  Update a step on a test-definition. patch = { step?, data?, expectedResult? } (subset).

• test_exec_history

  List test-execution tickets for a given test-definition, sorted by runAt descending. Use the resulting executions[].id to recordTestExecStep / setTestExecOutcome.

• test_exec_record

  Record per-step result on a test-execution. stepId may be either the definition-step id (clone source) or the execution-step's own id. patch = { actualResult?, status?, note? } where status ∈ pending|passed|failed|blocked|skipped.

• test_exec_set_outcome

  Set the manual outcome override on a test-execution. outcome ∈ pending|passed|failed|blocked|skipped or 'auto' to reset (let deriveOutcome take over). The 'auto' form clears outcomeOverride.

• test_exec_start

  Start a test-execution run. Creates a new test-execution ticket, clones the definition's steps (snapshot semantics — later definition edits don't bleed back), opens an 'executes' link to the definition, sets runAt=now and runBy=actor (or opts.runBy). opts = { env?, runBy? }. Returns the new execution ticket. SM-94: definition must be in lifecycle='published' — fails with kind=DEFINITION_DRAFT othe

• ticket_createwrite action

  Create a ticket. Pass acceptanceCriteria as [{text}] to set them at creation (no more create-then-update). The DoR/DoD checklists are resolved from the project's definitions for this ticket type and FROZEN onto the ticket. Compact response by default ({revision, savedAt, ticket:{id, ticketKey, type, status, title, position}}); pass verbose:true for the full ticket.

• ticket_deletewrite action

  Soft-delete a ticket

• ticket_get

  Get a ticket by id (includes frozen DoR/DoD checklists). Default

• ticket_updatewrite action

  Patch a ticket (title, description, type, position, labels, acceptanceCriteria).

• update_test_definition_metadatawrite action

  Edit cosmetic metadata on a test-definition (title, description, labels). Deliberately small surface — does NOT touch steps, prerequisites, or lifecycle. Safe to call on both draft and published definitions: the spec stays frozen, only the human-facing labelling changes.

• Code scan49 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 67 days ago12/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

88/100

higher than 70% of 866 Scraping and browsing servers

Tools

70

the typical Scraping and browsing server has 6

Tools that change things

39%

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

GitHub stars

1

more than 50% of 583 Scraping and browsing servers

Downloads a week

37

more than 18% of 309 Scraping and browsing servers with a package

Story Mapper: common questions

Is Story Mapper MCP server safe?

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

How do I install Story Mapper?

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

Does Story Mapper need an API key?

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

Is Story Mapper maintained?

The last commit was 107 days ago (2026-07-20). The latest release is v1.0.1.

What can I use instead of Story Mapper?

Servers from other publishers that do the same job: Agent Browser MCP server, Next AI Draw.io MCP server and Vessel Browser MCP server.

How does Story Mapper compare with other Scraping and browsing MCP servers?

safety score 88/100 (higher than 70% of 866 Scraping and browsing servers); tools 70 (the typical Scraping and browsing server has 6); tools that change things 39% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.