Vibemap MCP server

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

• vibemap_analyze_codebase

  Scan a local codebase and submit it to VibeMap for AI-powered reverse engineering. The server-side generation persists FEATURES from the code digest. It does NOT persist user stories or acceptance criteria — after the features task completes (poll vibemap_get_generation_status), create those yourself with vibemap_create_user_story and vibemap_create_acceptance_criterion, using your full codebase a

• vibemap_block_criterion

  Mark a criterion as blocked. Transitions any-active-status → blocked. Use this when external dependency, ambiguity, or environmental issue prevents progress.

• vibemap_claim_criterion

  Atomically claim an acceptance criterion for implementation. Transitions ready → in_progress. Returns 409 (race) if another agent already claimed it.

• vibemap_create_acceptance_criterionwrite action

  Create a new acceptance criterion for a user story in BDD format (Given/When/Then). Use this to flesh out what 'done' means for a story before or during implementation. You can call this multiple times to add multiple scenarios (happy path, error cases, edge cases) to the same story.

• vibemap_create_featurewrite action

  Create a new feature in a VibeMap project. Use this when reverse-engineering a codebase to register discovered capabilities.

• vibemap_create_pagewrite action

  Create a page/screen in a VibeMap project's page inventory. Author pages after features, stories, and criteria to capture the app's screens and routes. Existing pages are visible via vibemap_get_project_context — enrich, don't duplicate.

• vibemap_create_personawrite action

  Create a user persona in a VibeMap project. Personas are the cast of users the spec is written for — author them FIRST, then reference each persona's role (userRole) when writing user stories. Match the depth VibeMap's own generator produces: fill the structured blocks so the persona is rich and semantically searchable, not just a name. Existing personas are visible via vibemap_get_project_context

• vibemap_create_projectwrite action

  Create a new VibeMap project. Use this when starting from an existing codebase — create the project first, then call vibemap_analyze_codebase with the returned project ID.

• vibemap_create_schemawrite action

  Persist a VibeMap project's database schema — tables, columns, and relationships — in one call. Author this LAST, after the rest of the spec exists, grounded on the spec (idea-first) or the codebase's models/migrations (code-first). One table per domain entity; give every table an `id` primary key and created_at/updated_at; set real Postgres column types + constraints; express foreign keys via eac

• vibemap_create_user_storywrite action

  Create a new user story inside a VibeMap feature. Provide the user role, action, and expected outcome.

• vibemap_get_atomic_blueprint

  Retrieve a code-shaped atomic blueprint of a VibeMap project — relationships hydrated, Kanban metadata stripped, with synthesized interactions and entity state machines. Designed for LLM coders building the application end-to-end. Prefer this over vibemap_get_project_context when generating code; the blueprint omits PM narrative and process metadata to maximise signal-per-token.

• vibemap_get_code_map

  Fetch the project's current code map (status draft|confirmed, nodes/edges, sync anchor incl. any drift report). Use before re-submitting to preserve the user's hidden-node curation where possible.

• vibemap_get_generation_status

  Poll the status of a VibeMap AI generation task (e.g., reverse engineering or spec generation). Use the sessionId returned by vibemap_analyze_codebase.

• vibemap_get_kanban_board

  Get a real-time kanban board view of a project grouped by status columns. Shows features with their stories nested underneath. Ideal for an IDE agent to understand what's planned, in progress, and done.

• vibemap_get_next_ready_criterion

  Get the highest-priority acceptance criterion in `ready` status for the given project. Returns the criterion to work on next, or null if nothing is ready.

• vibemap_get_page_source

  Retrieve a VibeMap page's generated source code so you can pull it straight into a repo. Returns the page's own source_code plus the source_code of each of its sections. Use this to export a generated page into your codebase instead of copy-pasting.

• vibemap_get_project_context

  Retrieve the full context of a VibeMap project including features, user stories, personas, pages, and database schema. Use this before building a feature to understand all the specs.

• vibemap_list_acceptance_criteria

  List acceptance criteria for a story, feature, or project. Returns BDD-formatted criteria (Given/When/Then) with status.

• vibemap_list_access_rules

  List a VibeMap project's access-control rules: table-level rules (per persona/role, with can_select/insert/update/delete and structured op_conditions predicates like "own rows only") and page-level rules (can_view/create_content/edit/delete with predicates), plus an advisory reconciliation summary flagging page↔table drift. Use this to generate correct RLS policies and route/UI authorization — the

• vibemap_list_changesets

  List a VibeMap project's version-control changesets (most recent first) with a per-changeset op count. Every write you make through this server is wrapped in a changeset, so use this to see the changesets your own edits produced, audit who/what changed the project, or review recent edit history. Pass includeOps=true to inline each changeset's individual operations (entity_type, op, diff).

• vibemap_list_features

  List features for a VibeMap project. Supports filtering by status, priority, category, and search. Returns paginated results.

• vibemap_list_kanban_events

  List kanban transition events for a project, newest first. Use `since` to fetch only events after a timestamp (for reconnect-backfill).

• vibemap_list_projects

  List all VibeMap projects for the authenticated user. Returns project IDs, names, descriptions, and status.

• vibemap_list_user_stories

  List user stories for a project or feature. Filter by status, priority. Returns paginated results with full story detail.

• vibemap_report_progress

  Append a progress event to the criterion timeline without changing its status. Used to surface intermediate work for visibility.

• vibemap_resolve_review

  Resolve a criterion in review. Transitions in_review → passed | failed. NOTE: agents (env_token:agent) cannot self-resolve their own work — this tool requires a CI-scoped token (env_token:ci) or a session user.

• vibemap_scan_codebase

  Scan a local directory and return a formatted tree view plus file statistics. Use this to explore and understand an existing codebase before syncing to VibeMap.

• vibemap_submit_code_mapwrite action

  Submit a structural code map of the user's codebase to VibeMap (rendered on the project's Codebase tab). Build it yourself from your codebase access: one node per meaningful unit (page/route, API endpoint, data model, service, module, config), edges for imports/routes/reads/writes. Node kinds: page|api|model|service|module|config. Layers: ui|api|data|services|shared. Edge kinds: imports|routes|rea

• vibemap_submit_for_reviewwrite action

  Submit completed work for review. Transitions in_progress → in_review. Requires a git SHA and a diff URL as evidence.

• vibemap_sync_changes

  Report codebase changes since the last sync so VibeMap can flag spec drift. Workflow: 1) call vibemap_get_code_map and read anchor.commitSha; 2) run `git diff --name-only <commitSha>..HEAD` (plus untracked files from `git status --porcelain`); 3) call this tool with the changed paths and your current HEAD sha. The response lists affected map units and features — update the stale specs with vibemap

• vibemap_unblock_criterion

  Unblock a criterion. Transitions blocked → prior_status (recorded when block was set; defaults to ready).

• vibemap_update_acceptance_criterionwrite action

  Update an acceptance criterion's status or content. Use status 'passed' when your code satisfies the criterion, 'failed' when it does not.

• vibemap_update_featurewrite action

  Update an existing feature's fields or status in VibeMap.

• vibemap_update_kanban_statuswrite action

  [DEPRECATED — use the typed transition tools (claim, report_progress, submit_for_review, resolve_review, block, unblock) instead. This tool will be removed in a future release.] Atomically advance or update the kanban status of a feature, user story, or acceptance criterion. Validates allowed state transitions and prevents invalid moves. Call this when you start or finish implementing something. F

• vibemap_update_user_storywrite action

  Update an existing user story's fields or status in VibeMap.

• Code scan7 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 qualitystatic API keys via environment variables6/15
• Maintenancelast push 4 days ago15/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

83/100

higher than 77% of 2,174 E-commerce servers

Tools

35

the typical E-commerce server has 6

Tools that change things

37%

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

Downloads a week

28

more than 18% of 411 E-commerce servers with a package

Vibemap: common questions

Is Vibemap MCP server safe?

Mostly: it is graded B (83/100). Read the Vibemap safety report

How do I install Vibemap?

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

Does Vibemap need an API key?

Yes. The registry entry asks for VIBEMAP_API_KEY.

Is Vibemap maintained?

The last commit was 45 days ago (2026-09-20). The latest release is v2.8.1.

What can I use instead of Vibemap?

Servers from other publishers that do the same job: Loki Mode MCP server, PostHog MCP Server and New-Term Radar MCP server.

How does Vibemap compare with other E-commerce MCP servers?

safety score 83/100 (higher than 77% of 2,174 E-commerce servers); tools 35 (the typical E-commerce server has 6); tools that change things 37% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.