Docs

Remote MCP

The hosted FlyDocs MCP server: one URL, one sign-in, the same lifecycle rules as the CLI. What it is, who it is for, and how it differs from the local server.

Remote MCP is a hosted FlyDocs server at https://mcp.flydocs.ai/mcp. You add the URL to an AI client, sign in with your FlyDocs account, and the client can read and work your issue tracker through FlyDocs. There is no API key to paste, no repository to clone, and nothing to install for Claude Desktop, claude.ai or ChatGPT.

Every write still goes through the FlyDocs relay, the service the CLI uses. The relay enforces the workflow for everyone, so the same status moves are legal and the same ones are refused, whether the call comes from a terminal or a chat window.

Who it is for

  • Product managers, leads and marketers who work in a chat client instead of a terminal: triage a backlog, refine an issue into a spec, post a weekly update, ask what shipped, draft a release post.
  • Engineers who want the tracker from a chat client, or from an agent on a machine without a checkout.

Remote MCP is not a separate plan or an add-on. Every member of your organization is one seat, and every seat reaches the same tools. See Billing & Plans. Two things can narrow what a call does: the relay's workflow rules, which apply to everyone, and an admin switching Remote MCP off for the organization.

Two MCP servers, two jobs

FlyDocs has two MCP servers. They run side by side and never share a name, a login or a permission rule.

Local server Remote server
Command / URL flydocs mcp https://mcp.flydocs.ai/mcp
Registered as flydocs flydocs-cloud
Registered by flydocs init and flydocs connect, per project flydocs connect remote, per machine, or by pasting the URL into a client
Runs On your machine, over stdio, started by your editor Hosted by FlyDocs, over HTTPS
Sign-in Your API key from the CLI Your FlyDocs account, through OAuth
Needs The CLI and a FlyDocs project on disk A FlyDocs account and a client that supports remote MCP
Best at The coding loop: sessions, hooks, the issue lifecycle next to the code Backlog work, project context, delivery reporting and release copy, away from the code

If you write code with FlyDocs installed, you already have the local server, and you do not need the remote one to do your job. Add the remote server when you also want the tracker, the project context or the delivery reports from a client that has no checkout, or when you are the person who does not run a terminal. The two can be connected at the same time. The local setup is covered in Tool Surface Setup.

Skills carry the method; MCP carries the tools

The MCP server gives an agent tools it can call: read an issue, move it, tick a criterion, size a plan. It does not tell the agent how your team works. That is what skills are for. A skill is the written method: how to triage, what a refined spec looks like, which order to read things in, when to stop and ask. FlyDocs uses both. The local server pairs with the workflow skills in your repo, and the remote server pairs with the connector's built-in instructions, its prompts and a downloadable skill.

What it does not do

  • It never returns source code. It reads the tracker, the project context your team publishes, and records about what shipped. File paths and line counts can appear. File contents and diffs do not.
  • It does not skip the relay. A call that the lifecycle would refuse from the CLI is refused here, with the reason.
  • It cannot delete a milestone or archive a project. Both are hard to undo from a chat window, so both are admin work in the portal or in your tracker.

Next