Beta: Connect AI tools directly to Workflowy with Local MCP

We’ve added a Local MCP server to the latest Workflowy desktop beta.

It allows MCP-compatible AI tools running on your computer to read and edit your Workflowy through a fast local connection—without an API key or API rate limits.

To try it:

  1. Download the latest Workflowy desktop beta.
  2. Open the More Menu and select Settings.
  3. Scroll down to MCP.
  4. Enable Local MCP.
  5. Copy the generated connection link into your AI tool’s MCP settings.

The server runs locally on your computer. Treat the connection link as sensitive: don’t post it publicly or share it with tools you don’t trust. You can also change the port if the default conflicts with another application.

This is an early beta feature. We’ve successfully tested it on macOS, but your mileage may vary depending on your operating system and MCP client.

If you try it, we’d especially like to know:

  • Which AI tool and operating system are you using?
  • Were you able to connect successfully?
  • Did the available Workflowy tools behave as expected?
  • Was any part of the setup confusing?

Share what worked—and where you got stuck.

4 Likes

I operate on Mac OS. I use Perplexity as my AI tool. When I tried to add this as a new connector I received an error message which said “[API_CLIENTS_ERROR] Server does not support automatic registration.”

1 Like

Tried it today — answers to your four questions:

Which AI tool and operating system? Claude Code on macOS (Apple Silicon). Claude Code did the setup and testing itself, driven from a chat session.

Were you able to connect successfully? Yes, first try. Added the connection link as an HTTP MCP server in the client’s config file; the handshake and tool listing just worked.

Did the tools behave as expected? Yes, and read performance is outstanding: a text search from the root of an account with a few hundred thousand items returned in under a tenth of a second, where API-based tools take seconds per call. Two things stood out. First, tree_seek resolves mirrors to their original text — the public API cannot see mirrors at all, so this alone is a big deal for anyone whose workflow leans on mirroring — and it even labels mirrors whose original was deleted. Second, a full write round trip with tree_patch (create an item, verify it, delete it) worked cleanly.

Was any part of the setup confusing? No, setup was clear. Two small requests: (1) tree_patch doesn’t appear to support writing an item’s note field, so anyone keeping structured metadata in notes still needs the API tools for writes — note support would let this replace them entirely; (2) it would help if the docs mentioned that the 12-character item IDs are the last segment of an item’s full internal ID, i.e. the same fragment that appears in workflowy.com URLs.

Overall: dramatically faster than the API for reads, and mirror-awareness makes it the better read path already. Really promising feature.

(p.s. Claude found this page and wrote all that after suggesting I contribute feedback as requested).

1 Like

Thanks for testing this, and welcome to the community!

Perplexity’s current local MCP setup expects a command it can launch, while Workflowy provides a local HTTP connection link. It appears Perplexity is treating that link as a remote OAuth connector, which is why automatic registration fails.

For now, I’d consider Perplexity unsupported with this beta… but this is useful compatibility feedback. Thanks for reporting it.

1 Like

This is exactly the kind of field report we were hoping for, thanks, and welcome to the community!

Great to hear the setup worked on the first try and thank you for both requests.

1 Like

I am trying to connect the MCP server to Cursor.

It tells me that it is able to reach the MCP server because the toast message it sent appeared but nothing is coming back.

Here’s what it told me.

Good news that the toast appeared — that confirms calls are reaching Workflowy and executing; only the responses back to me are being dropped.

1 Like

I asked cursor to try with curl and this is what happened.

Yes — curl works, and everything succeeded. The mock node :test_tube: Mock node (MCP curl test) was created at the top level, right after ♖ DashBoard. Check your Workflowy to confirm.

Root cause of the Cursor problem: the raw responses show your server returns only structuredContent in tool results, with no content array:

{“result”: {“structuredContent”: {“results”: [“…”]}}}

Cursor’s MCP client apparently drops results that lack the standard content text blocks — that’s why I saw “(omitted)” for every call. The fix on your server: also include content: [{type: "text", text: "..."}] in each tool response.

1 Like

Thanks for your feedback and update @hertzsteven .

1 Like

Roberto, disculpa mi ignorancia. ¿Cómo puedo configurarlo con Gemini en un Mac que utiliza Intel o no es posible?

1 Like

Hola Rodolfo, disculpa mi ignorancia. ¿Cómo puedo configurarlo con Gemini en un Mac que utiliza Intel o no es posible?

Hola Carlos, no hace falta disculparse. Sí, debería ser posible en un Mac con procesador Intel. La opción documentada para conectarlo es Gemini CLI.

Con la beta de Workflowy abierta:

  1. Ve a Settings → MCP, activa Local MCP y copia el enlace de conexión.
  2. Instala Gemini CLI si todavía no lo tienes:
npm install -g @google/gemini-cli@latest
  1. Añade Workflowy desde Terminal:
gemini mcp add --transport http --scope user workflowy "PEGA_AQUÍ_EL_ENLACE"
  1. Comprueba la conexión:
gemini mcp list

Mantén Workflowy abierto y prueba primero con una consulta de lectura. No hemos probado todavía esta combinación exacta de Gemini CLI y Mac Intel, así que si falla, compártenos el mensaje de error y las versiones que estás usando. No publiques el enlace de conexión, ya que es privado.

1 Like

Hi Rodolfo

Following on from my first report, Claude wanted to add something:

I use the MCP server built into the WorkFlowy Beta desktop app on macOS, currently 4.3.2608051824-beta, and it has become the main way I work with my account. It is fast, it resolves mirrors, and nothing has to leave my machine. It is genuinely very good.

There is one gap, and it is a big one for me: the note — the grey text under a bullet — is not exposed at all. I cannot read a note, write one, edit one, or clear one through any of the local tools.

I checked this by asking the running server for its own tool list rather than going by documentation. It offers seven tools: tree_seek, tree_zoom, tree_patch, message_success, attachments_pull, attachments_attach and screencap_capture. None of them has a note parameter.

Concretely:

  • tree_patch is the only tool that changes anything, and its full set of operations is replace (bullet text only), complete, uncomplete, insert_after, insert_before, move and delete. There is no note field on any of them, including the two insert operations, so I cannot even create a bullet with a note already attached.
  • tree_seek leaves notes out of its results entirely. Reading a bullet whose note says “KANBAN” gives me the bullet text and nothing more. I could not find a flag to include notes.

Why this matters: notes are where the actual information lives for a lot of us. Every task in my account carries info like due date, effort estimate, blocking dependency and owner in its note. So the local server can do everything to a bullet except touch the part that holds its data, and anything that maintains that data has to fall back to the cloud API — which means depending on a network connection, sending data off the machine, and maintaining two connections instead of one. That undoes much of the reason to have a local server.

What I would like:

  1. Notes included in tree_seek results, ideally behind an optional flag so existing callers do not suddenly get much larger responses.
  2. A note parameter on tree_patch — on insert_after and insert_before so a bullet can be created complete, and either on replace or as its own replace-note operation.
  3. A way to clear a note back to genuinely empty and deleted.

On that third point, in case it is useful to whoever picks this up: clearing a note appears to be impossible through the public API too, not just locally. Sending empty text returns “specify at least one of name, note, or layout_mode”, which I assume is a guard against empty requests but which also blocks clearing on purpose. A single space is rejected the same way through MCP. It works through the command-line tool only if the space is passed as a separate argument — --note " " succeeds while --note=" " fails — and the bullet then holds a note containing one space, which looks blank but is not.

One small documentation point while I am here. The command-line tool describes --note as “Additional note content”, which reads as though it appends to an existing note. It does not — it replaces the note completely. I lost a note finding that out. Wording it as a replacement would save someone else the same.

Happy to give more detail on any of this if it is helpful. Thanks for the local server — the note field is the only thing standing between it and being all I need.