What flanner MCP server does
The flanner MCP server gives AI coding agents a managed place for plans, design notes, migration documents, and other Markdown artifacts. It creates a project-specific .plans/ directory, adds YAML frontmatter, and records each revision as a separate version with its history intact. Plans are excluded from commits automatically until a developer chooses to include them.
The project also includes a local browser interface for reading, editing, and reviewing plan history. The interface works offline and can be opened with flanner web --open-browser. Per-project settings allow repositories to use a customized plan directory.
Beyond plan files, Flanner includes durable memory for searchable project context, skill discovery and diagnostics, and Curb commands for examining agent access to credentials and possible outbound channels. Team Mesh features support device-to-device messages and peer plan serving. Issue links are present but disabled in the current build; Linear or JIRA support is described as not yet supported.
How it works
Running flanner init detects the Git root, creates the project database and .plans/ directory, updates .gitignore, and installs the agent instructions and guard hook. It also registers the MCP server for the configured agents. Claude Code reads the generated project .mcp.json; Claude Desktop receives a user-level registration; and Codex uses AGENTS.md plus its ~/.codex/config.toml configuration.
The installed package places both flanner and flanner-mcp on the path. Agents start the MCP process by its name, so an installation hidden inside a project virtual environment may not be visible to an agent launched elsewhere. The server can also run in the background over HTTP with flanner start, while flanner peer start serves plans to teammates.
Memory commands can save, search, list, inspect, supersede, share, or withdraw durable context. Memory capture has selectable modes, and the README states that proposed entries require approval by default and credential-like content is refused. Skill commands scan packages from the project, home directory, and installed plugins without executing their contents.
Setup and configuration
Install with one of the documented Python package methods:
uv tool install flanner
pipx install flanner
pip install flanner
From a Git repository, run flanner init. The command is safe to repeat and supports project-root and plan-directory options. --setup selects the agent registration target, while --skip-claude writes repository files without registering an agent. flanner init --sync imports plan files that are already committed in an adopted repository.
The project also offers a desktop application for Windows, macOS, and Linux. It bundles the web interface, command line, MCP server, background synchronization, and updates, so Python is not required for that distribution.
Tools and capabilities
The flanner MCP server exposes plan-file operations to connected agents. The surrounding CLI supports these areas:
- Create and initialize projects, list plans, synchronize existing files, and change project configuration.
- Browse and revise plans through the local web interface.
- Save and search durable memory with
mem remember and mem recall.
- Inspect loaded skills with
skills scan and diagnose conflicts with skills doctor.
- Review agent exposure with
curb map, inspect findings with curb show, and search local artifacts for secrets with curb sweep.
- Apply or review organization policies, inspect fleet status, generate CI SARIF results, and verify agent commit signatures when the related Curb features are configured.
- Send teammate messages with a preview step and manage peer plan serving.
Limitations and notes
Linear and JIRA issue linking is off in the supplied build. The README says integrations are built but not supported yet, and mentions FLANNER_INTEGRATIONS=1 plus LINEAR_API_KEY for the unfinished integration path. The hosted Mesh service handles identities and access decisions but does not hold plan contents, according to the project documentation.
The default workflow is local-first. Team synchronization uses encrypted direct connections between machines rather than uploading plan contents to a central server. Curb inspection is described as read-only; sensitive details are withheld from summary output unless an operator explicitly opens the relevant view. A signature identifies the signing key, not the person who authored the code.