Skip to main content
This guide shows you how to connect a Model Context Protocol (MCP) client to the hosted WRITER MCP server. After you connect, you can run published playbooks, work with their outputs, and access your Writer Meet recordings from your MCP client.

​
Connect a client

WRITER MCP works with any MCP-compatible client. Every client connects to the same server at https://api.writer.com/v1/mcp and signs in with your Writer account. Select a client below for its setup steps, or use that URL with your own client’s instructions for adding a remote MCP server.
Install WRITER MCP from the Cursor Marketplace, or add the server URL yourself.
1

Open the plugin list

Open Cursor Settings, then Plugins.
2

Install the plugin

Search for WRITER MCP and select Install. You can also run /add-plugin writer-mcp in chat.
3

Sign in to Writer

Complete the Writer sign-in prompt in your browser, then choose one organization on the consent screen.
To add the server in config, put this entry in a project .cursor/mcp.json, or in ~/.cursor/mcp.json to use it in every project. Cursor asks you to sign in when you enable the server.
.cursor/mcp.json
Your client opens a browser so you can sign in. Choose one organization and approve the consent screen, and the connection is ready. Your playbooks, deliverables, and meetings all come from that organization. To switch organizations, connect again and choose the other one when you sign in.

​
Try these prompts

Ask for what you want in plain language and let the assistant choose the tools. Start with the first prompt to confirm the connection works:
  • “List the available Writer playbooks, then show the inputs for the Board update playbook.”
  • “Run the Board update playbook with the attached Q3 brief and report when it finishes.”
  • “Download the deck from the most recent playbook run into this folder.”
  • “Summarize the Writer Meet calls about the Q3 launch from the last two weeks.”

​
Run a playbook

Runs are asynchronous. run_playbook returns a run_id right away and the run continues in the background, so the assistant polls get_run until the run finishes. A run can also stop at awaiting_user to ask you a question, and it stays there until you answer. A typical run follows this sequence:
  1. get_playbook returns the playbook’s inputs.
  2. upload_file uploads a file for any input that expects one.
  3. run_playbook starts the run and returns a run_id.
  4. get_run reports the status until the run finishes.
  5. resume_run answers the run if it stops at awaiting_user, then polling continues.
  6. get_run_output returns the final text and the run’s deliverables.
Run tools also return a thread_url. Open it to see the run in Writer, signed in with an account that can access the thread.

​
Download a deliverable

A playbook can produce files, which Writer calls deliverables. The assistant downloads them in chunks and reassembles the file for you.

​
Read a Writer Meet recording

Writer Meet records your meetings and generates a transcript and summary. Both tools cover only the meetings you joined, never your whole organization.

​
Understand access and authentication

A connection covers one organization: the one you chose when you signed in. A run uses the team that owns the playbook, and you still need access to that playbook. list_runs and get_run return a run only when you started it through WRITER MCP. Access tokens last one hour and refresh automatically. Sign in again if your client prompts you, which can happen after a day.

​
Next steps