MCP Tool Reference

PAPI tool reference

PAPI exposes workflow tools through MCP. Your AI client can call them as you direct the workflow in plain language.

Typical workflow
orient→plan→build_list→build_execute→review_submit→release

Getting Started

setup

Initialise PAPI for your project. Generates a Product Brief, seeds Active Decisions, and scaffolds workflow instructions. Run once per project after installing.

↳First thing after connecting PAPI to a new project.
orient

Single-call session orientation. Returns your current cycle, task counts by status, velocity snapshot, and recommended next action.

↳At the start of every session. Run this before anything else.

Planning

plan

Generate BUILD HANDOFFs for the next cycle. Two-phase: prepare assembles context and returns a planning prompt, apply writes the results. PAPI selects and scopes tasks based on your backlog, active decisions, and velocity history.

↳Once per cycle, after completing all builds from the previous cycle.
Never run more than once per cycle. Use board_deprioritise to adjust scope instead.
build_list

List cycle tasks with their BUILD HANDOFFs ready for execution. Shows In Progress first, then Backlog.

↳After plan to see what's ready to build, or to pick your next task.
build_describe

Show the full BUILD HANDOFF for a specific task — scope, acceptance criteria, relevant files, and effort estimate.

↳Before starting a task, or to re-read the brief mid-build.

Building

build_execute

Start or complete a build task. Call once to start (creates a feature branch, returns handoff). Call again with a build report to complete (records effort, surprises, discovered issues, and creates a PR).

↳Before and after implementing each task. The start/complete cycle is required.
build_cancel

Cancel a build task with a reason. Moves it back to backlog.

↳When a task turns out to be a duplicate, is blocked, or should not be built this cycle.
idea

Capture an idea, improvement, or bug as a Backlog task for the next cycle's plan to triage. Doesn't interrupt the current cycle.

↳Any time you spot something worth doing. Captures intent without blocking the current build.
bug

Report a bug as a prioritised Backlog task. Severity determines the priority assigned.

↳When you find a bug during a build or session.
ad_hoc

Record quick work done outside the normal cycle — no branch, no PR, just a log entry. Keeps your cycle history accurate.

↳For quick fixes, config changes, or small edits that don't need a full build cycle.

Review & Release

review_list

List tasks waiting for review — those that have been built but not yet accepted.

↳After building, to see what needs sign-off before release.
review_submit

Record your verdict on a completed build. Accept merges the PR and marks the task Done. Request-changes sends it back. Reject cancels it.

↳After reviewing a build. Accept triggers the merge.
release

Cut a versioned release — creates a git tag, generates a CHANGELOG entry, and pushes to remote.

↳After all cycle tasks have been reviewed and accepted.
close_cycle

Finish an accepted cycle with an unversioned CHANGELOG entry confirmed on the repository remote. Creates no tag or deployment.

↳After acceptance when you want to finish the cycle without publishing a release. Run through the caller workspace.

Conventions

convention_declare

Record a settled project build rule so future BUILD HANDOFFs carry it. Leave module empty for a project-wide rule, or scope it to one module.

↳When a recurring implementation choice is settled and should not be re-litigated in every cycle.
convention_list

List the project build rules, their scope, and the ids used to remove them. A module filter shows project-wide rules plus rules for that module.

↳When checking which settled rules apply before planning or building.
convention_remove

Remove a convention by id. This changes future handoffs; existing handoffs that were already generated keep their original guidance.

↳When a settled rule no longer applies or is being replaced.

Board

board_view

View the task board with optional filters by status, priority, or module.

↳To check board state, find a specific task, or understand the full backlog.
board_deprioritise

Move a task out of the current cycle back to backlog. Use this to adjust scope mid-cycle without cancelling.

↳When a cycle task needs to be deferred to a future cycle.
board_archive

Archive Done or Cancelled tasks to keep the board focused on active work.

↳Periodically to reduce board noise, or before a strategy review.
board_reconcile

Detect and fix board state mismatches — orphaned branches, missed completions, status drift between git and the board.

↳When board state looks wrong, or as part of session-start housekeeping.

Strategy

strategy_review

Run a strategy review — assesses Active Decisions, velocity, and project direction. Two-phase: prepare returns the review prompt, apply saves the results with recommendations for the next plan.

↳Every 5 cycles (hard-blocked at 7+). Best as a dedicated session with fresh context.
Strategy reviews compound. Don't skip them.
strategy_change

Capture a strategic direction change as a new or updated Active Decision — with reasoning, evidence, and confidence level.

↳When a direction change happens in conversation. Captures the why, not just the what.
zoom_out

Step back and get a high-level view of project direction, horizon progress, and strategic alignment.

↳When you want perspective beyond the current cycle.
hierarchy_update

Update your project's horizon, stage, or phase structure — reflecting meaningful shifts in project scope or direction.

↳When a strategy review identifies a horizon or stage transition.

Document Registry

doc_register

Register a research or planning document in the doc registry. Stores metadata, a structured summary, and any actionable findings — not the full content.

↳After finalising a research or planning doc.
doc_edit

Edit a registered doc in place: rename its path, change visibility, patch tags, summary, status or actions, or replace the body. A rename keeps its id and updates task references together.

↳When a registered doc needs a change, including a path rename, visibility move, or summary correction.
doc_search

Search the doc registry by type, tags, keyword, or pending actions. Returns summaries for context gathering.

↳Before planning, strategy reviews, or when looking for prior research.
doc_scan

Scan your docs directory for markdown files not yet registered in the registry.

↳To find docs that need registration, or at session start as part of housekeeping.
Ready to start?
Install PAPI and run your first cycle plan in under 5 minutes.
Install guide →Discord