MCP

zee-rp: Use MCP to Let AI Directly Read and Write Native Axure RP 11 Prototype Files

Lets AI directly read, edit, and generate native Axure RP 11 prototype files, but requires a local Node.js environment and npm-installed dependencies; writes only produce new files and never overwrite existing paths.

Official source · zee-rp

Install

git clone https://github.com/LilZeeCN/zee-rp.git && cd zee-rp && npm ci

zee-rp is an open-source engine and MCP server for reading, writing, and generating native Axure RP 11 prototype files (.rp). If your task is to have an AI assistant operate directly on real .rp documents — for example, reading prototype structure, batch-editing widget text, or cloning new pages from templates — it is one of the few options targeting the native .rp format; the prerequisites are that you are comfortable with the command line and Node.js, and willing to complete npm ci first to install dependencies (only the MCP part requires this). It is an independent project, unaffiliated with Axure officially, and licensed under MIT.

Who It's For

  • Design engineering teams that need AI to programmatically process Axure RP 11 prototype files: reading, modifying text, and generating new .rp output.
  • Users already working with MCP clients that support local stdio servers, who want to call tools for prototype reading, locating, inspection, interaction reading, editing, validation, and saving within a session.
  • When it's not a fit: if you just want to open a prototype and take a quick look (Axure itself is more direct); if you're unwilling to set up three environment variables locally for a blank template, a widget library directory, and an output directory; or if you expect to overwrite the original file — zee-rp's native writer only creates new output files and refuses existing target paths, requiring a new filename at every step.

Your First Try in 3 Minutes

The recommended main path is to clone the repository and start the local MCP server:

  1. Prerequisites: Node.js installed; MCP requires dependencies, so run npm ci.
  2. Installation:
git clone https://github.com/LilZeeCN/zee-rp.git
cd zee-rp
npm ci
  1. In your MCP client, configure a local stdio server pointing to bin/mcp.mjs inside the repository, and set three environment variables:
"command": "node",
"args": ["/absolute/path/to/zee-rp/bin/mcp.mjs"],
"env": {
  "AXURE_BLANK_TEMPLATE": "/absolute/path/blank.rp",
  "AXURE_LIBRARY_ROOT": "/absolute/path/DefaultSettings/Libraries",
  "AXURE_WRITE_ROOT": "/absolute/path/outputs"
}

Replace the paths with absolute paths on your machine; an MCP session also requires the directory containing the source file to be writable, because a working copy is created next to the source file.

  1. For the first call, start with read-only capabilities: use axure_open to open a .rp file and establish a session, then use rp_read or inspect to read its contents. Signals of success: the server starts normally, tools can be listed, and read calls return prototype structure data without creating any new files.

Once the read-only results look right, consider operations that write files, such as edit_text, verify, and axure_save; writes are constrained by the AXURE_WRITE_ROOT and AXURE_PROTECTED_PATHS path guards, and generation produces a new file rather than modifying the original.

Use Cases

Case 1: Inspect the structure and interactions of an existing prototype. Hand a .rp file path to axure_open to establish a session, then use locate to find the target page or widget, inspect to view properties, and read_interactions to read interaction definitions. Everything is read-only and no files are changed — ideal for getting familiar with a prototype before making modifications. If you're unsure about a particular widget, axure_state shows the current session state.

Case 2: Modify widget text and save as a new file. In the session opened via axure_open, use edit_text to change the target widget's text (you can also use set_widget_text from the command group), then use verify to validate the change, and finally axure_save to save. Note: saving generates a new output file, and the target path must not already exist — prepare a filename that doesn't exist beforehand. If a save gets stuck, jobs_list, jobs_get, and jobs_cancel in the GUI/jobs group can view and cancel tasks.

Usage Boundaries

  • Nature of reads and writes: read-type tools (such as rp_read, inspect, read_interactions) perform no write operations, but read-only does not mean zero risk — they still read local file contents.
  • Write side effects: the native writer creates new files and refuses existing targets; the MCP session's working copy is written next to the source file, so the source directory must be writable. axure_save is a real write action — confirm the target filename and output path before saving.
  • Path restrictions: write operations are constrained by AXURE_WRITE_ROOT, and AXURE_PROTECTED_PATHS can further protect paths.
  • Credentials: official evidence mentions no account, email, or API key requirements.
  • Not yet confirmed: official materials do not specify which MCP clients are supported, whether .rp versions other than RP 11 are compatible, or the exact requirements gui_roundtrip places on an Axure installation; verify these on your own before use.