Remote MCP

Remote MCP is FlyDocs for the people on your team who do not run a terminal. A product manager, a marketer, or an engineering lead connects Claude Desktop to a FlyDocs endpoint, signs in once, and works the tracker through the same server-side rules the CLI runs under. No API key to paste, no repo to clone.

Remote MCP is in beta. Availability depends on your plan and on the endpoints being enabled for your organization; the portal's Settings > MCP page shows the current state.

One connector

There is one endpoint, https://mcp.flydocs.ai/mcp. It carries every tool; your seat decides which of them you can call, and the connector's instructions, its prompts, and the persona skills below decide which ones Claude reaches for in a given job. The older persona URLs (/mcp/pm, /mcp/lead, /mcp/marketing) still work and serve the same tools, so an existing connection does not need to change.

What is on it, in the order Claude sees it:

• Reading the record: flydocs_whoami (which organizations and workspaces you can reach, and your seat in each), flydocs_issue_get, flydocs_issue_list, flydocs_change_context (what shipped for an issue) and flydocs_context_get (the project narrative your team maintains), plus a flydocs_server_info diagnostic.
• Working the backlog: flydocs_issue_create, flydocs_issue_update, flydocs_issue_comment, flydocs_issue_transition, flydocs_issue_assign, flydocs_issue_link, flydocs_project_update, and flydocs_issue_breakdown, which turns one issue into a set of template-checked sub-issues in a single call or refuses the whole set.
• Delivery analytics (Team plan): flydocs_kpi_summary, flydocs_spend_breakdown and flydocs_forecast, aggregates only, with a coverage note on every answer.
• Release copy: flydocs_release_digest, what a milestone, project, sprint or list of issues shipped, with a source under every claim.

Connect Claude Desktop

1. In Claude Desktop, open Settings > Connectors and choose Add custom connector. The label varies a little between versions; you are looking for the option that takes a remote MCP server URL.
2. Paste https://mcp.flydocs.ai/mcp.
3. Claude opens a FlyDocs sign-in. Sign in with the account you use for the portal. If you have more than one FlyDocs account, use the one that belongs to the organizations you want to work in.
4. Approve the consent screen. It asks for the mcp:tools permission, which is the only permission the endpoint uses.

That is the whole setup. Discovery of the sign-in server is automatic (the endpoint publishes standard protected-resource metadata), so there is nothing to configure by hand and nothing to rotate. Other OAuth-capable MCP clients follow the same steps with their own "add server" flow.

Organizations and workspaces

One connection covers every organization you belong to. Calls run in your primary organization: the Default Organization you set in account Preferences, else the organization of your Default Workspace, else the only one you are in. To act elsewhere, name it: Claude passes organization on the call. No reconnect.

Each call also acts on one workspace. When your seat can reach exactly one in that organization, it is chosen for you. When it can reach several, the first call comes back with the list of workspace slugs and asks you to name one; say which, and Claude passes it as workspace from then on. Ask "what do I have access to in FlyDocs?" first and Claude calls flydocs_whoami, which lists all of it.

"Show me FLY-1234 in the platform workspace."

What shipped, without the code

A product owner wants to know what the team built for an issue; a marketer wants to write about it. Neither has a repository, and Remote MCP never returns source code. flydocs_change_context answers from the records instead: the pull requests the issue names, and for each one what GitHub holds about it through the FlyDocs GitHub App, read on the server: whether it merged and when, the commit messages, the files that changed and the areas of the system they fall in. File contents and diffs never cross over. Every claim in the answer cites its source (the issue, a comment, a pull request number, a commit SHA) and says whether it was recorded or derived, so a sentence in a launch post can be traced back to the record that supports it.

flydocs_context_get pairs with it: the project.md and service descriptor your team publishes with flydocs context push, which is the description of the system you want Claude to use when someone asks how it fits together.

"What shipped for FLY-1300, in plain language?"

Reading a pull request needs the FlyDocs GitHub App installed for that repository and the repository linked to the workspace. When it is not, the answer still comes back from the tracker and names the pull request it could not read; Claude is instructed to say so rather than describe contents it did not see.

Prompts and the persona skills

The connector ships eight playbooks as MCP prompts, which Claude Desktop lists under the connector. Each composes the tools in the order the workflow expects and stops for your approval before it writes anything.

• Triage the backlog -- review what is in Backlog, propose a priority and a next step per issue, apply the ones you approve.
• Refine an issue into a spec -- read one issue, draft it in the workspace template with acceptance criteria, estimate and priority, link dependencies, mark it Ready.
• Write the weekly project update -- shipped, in flight, at risk, with references, and a health rating you confirm before it posts.
• What shipped for an issue -- the change context in plain language for someone who does not read code, a reference under every claim.
• Break an epic into sub-issues -- draft the children in the workspace template, dry-run them against it, fix what it names, then create the whole set on your approval.
• Draft a feature brief -- a post or announcement from a shipped issue and the project narrative, sourced sentence by sentence, shown to you before anything is recorded.
• Draft a release post -- the same for a milestone, project, sprint or list of issues, from the release digest.
• Report on a window of delivery -- what shipped, what it cost, how fast, with the coverage caveat attached. Reads only.

The playbook is delivered to Claude as the connector's instructions the moment it connects, so you get it without installing anything. If you use Claude Skills, the same content is packaged three ways, one per role, each with the shared rules plus that role's sections: flydocs-pm.zip (backlog and intake), flydocs-lead.zip (delivery analytics) and flydocs-marketing.zip (briefs, release posts, proposals). Add the one that matches your job under Settings > Skills.

Seats: what each member can do

An org admin assigns each member a seat on Settings > Members. Seats are per organization and take effect on the member's next call -- nothing is cached in the sign-in token, so a change never waits for a token to expire.

A seat is a seat. A product manager, lead, or marketer who works from Claude Desktop is an ordinary member on the same per-seat price as an engineer; there is no separate plan or add-on for Remote MCP. The seat class below is a permission an admin sets, not something you buy.

The seat is not the security boundary. It decides what a call is entitled to try; the relay decides whether the tracker accepts it. A leaked connection cannot do anything a valid one could not.

What the relay refuses, and why

Every write goes through the FlyDocs relay, the same service the CLI uses. Its rules do not bend for the remote surface, and when it says no it says why, in a structured response Claude reads back to you. The refusals you will meet:

• Delivery-lane transitions need evidence. Moving an issue to In Progress, Review, Testing or Done requires an assignee, a working session, acceptance criteria in the right state, and for Done a linked pull request. A PM seat cannot fake those, and neither can an engineer. The response names the missing evidence.
• Every status change carries a comment. A transition without one is refused before it reaches the tracker. Tell Claude why the issue is moving and it will include it.
• Illegal transitions are refused. The lifecycle is a state machine. Backlog to Done is not a move; the response says what is reachable from the current state.
• Assignees must be workspace members. Naming someone outside the workspace returns the roster so the next attempt lands.
• Seats have rate limits, and intake writes that touch many issues at once sit under a tighter one. "Clean up the backlog" is throttled by design.

This is deliberate. The value of letting a non-engineer write to the tracker is that the write is governed; a batch that half-lands, or a ticket closed without the work behind it, costs more than it saves.

Audit and revocation

Every call -- read or write, accepted or refused -- is logged with who made it, from which seat and persona, which tool, and the outcome. Org admins see the log on Settings > Audit.

To strip a member's write access immediately, set their seat back to Default. To cut them off entirely, remove them from the organization. Behind the scenes each member's remote access runs through a delegated API key named "Remote MCP (delegated)" in their account's API keys; revoking it blocks the remote surface for that member in that organization until an admin restores it.

What Remote MCP is not

It never returns source code. The endpoints read the tracker, the workspace's curated context, and (as they land) delivery analytics; no repository content crosses the boundary into a desktop transcript. And it does not replace the CLI for engineers: sessions, hooks, and acceptance evidence still come from the delivery lane.