anytype-mcp: An MCP Server That Turns the Anytype OpenAPI Spec Into Tools
An MCP server enabling AI assistants to interact with Anytype - your encrypted, local and collaborative wiki - to organize objects, lists, and more through natural language.
At a glance
- What is it?
- anyproto/anytype-mcp is a TypeScript MCP server that exposes Anytype's local HTTP API to AI assistants by converting the OpenAPI specification into callable tools. It is a thin, local-only bridge: it needs a running Anytype desktop instance, an API key, and an MCP client that can spawn npx.
- Who is it for?
- Adopt anytype-mcp if you already run the Anytype desktop app on the same machine as your MCP client and want conversational control over spaces, objects, properties and tags. Do not adopt it if you need a headless server, a remote or multi-user deployment, or if you cannot keep the Anytype app running and reachable at the configured base URL.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Anytype Has an API, Assistants Cannot Call It
Anytype ships an HTTP API, and the repository anyproto/anytype-api holds its OpenAPI specification. An OpenAPI document describes endpoints, parameters and schemas in a machine-readable form, but an AI assistant does not consume OpenAPI documents. It consumes tools. Somebody has to sit between the two and translate. That translation layer is what anytype-mcp is. The README states the server works by converting Anytype's OpenAPI specification into MCP tools, which means the tool surface is derived from the spec rather than hand-written endpoint by endpoint. The audience is narrow and specific: people who already keep a personal Anytype space and want an assistant to create objects, list them, set properties, and assemble collections through conversation instead of clicking through the app. The README's own examples are the clearest statement of scope. They include creating a space, adding a Task object with a title, then creating a second task with a due date three days out, and finally building a collection titled Tasks for this week that holds both. That is personal knowledge-base work, not team infrastructure.
What the Generated Tool Surface Actually Covers
The feature list in the README names five areas: global and space search, spaces and members, objects and lists, properties and tags, and types and templates. Read that list as a description of the API's own structure, because that is where it comes from. Anytype's data model is space-scoped. A space contains objects, objects carry properties, properties can be tags, and objects conform to types that may have templates. The MCP tool surface mirrors that hierarchy, which is why the example interactions move from space creation to object creation to collection assembly in that order. The consequence for users is that the assistant needs a space to be named or inferred before it can do almost anything useful. There is no separate abstraction layer on top of the API, no simplified command vocabulary, and no opinionated wrapper. If the OpenAPI spec describes an operation, it can plausibly surface as a tool; if the spec does not describe it, the MCP server has nothing to expose. That is the design's main virtue and its main limitation in the same breath. The README does not enumerate the individual tool names, so the exact list has to be read off a running server rather than from the documentation.
The Local-Only Constraint and the Base URL
The server does not talk to a cloud service. It talks to an Anytype instance running on your machine. The README states that by default the server connects to http://127.0.0.1:31009, and that for anytype-cli, which listens on port 31012, or for other custom base URLs, you set ANYTYPE_API_BASE_URL. This is the single most important operational fact about the project. The MCP server is a client of a local daemon, and if that daemon is not running, nothing works. It also means the security boundary is your own machine. The API key is passed as a Bearer token in an environment variable, and the README's configuration examples show it inline in the MCP client config as part of the OPENAPI_MCP_HEADERS JSON string. That string carries two headers: Authorization with the Bearer token, and Anytype-Version, which the examples pin to 2025-11-08. The version header is not decorative. It tells the API which version of the interface you expect, and a mismatch between that pinned value and the app you have installed is a plausible source of confusing failures. The README does not describe the failure mode, so treat this as something to check rather than something documented.
Getting It Running: The Two Configuration Paths
There are two ways to install, and the README treats the npx route as the default. For Claude Desktop, Cursor, Windsurf, Raycast and similar clients, you add a block to the MCP client settings with command set to npx, args set to ["-y", "@anyproto/anytype-mcp"], and an env object containing OPENAPI_MCP_HEADERS, a JSON string with the Authorization and Anytype-Version headers. For Claude Code specifically, the README gives a single command: claude mcp add anytype -e OPENAPI_MCP_HEADERS='{"Authorization":"Bearer <YOUR_API_KEY>", "Anytype-Version":"2025-11-08"}' -s user -- npx -y @anyproto/anytype-mcp. The second path is a global install with npm install -g @anyproto/anytype-mcp, after which the client config uses command anytype-mcp with no args. Both paths need an API key, which you create in Anytype under App Settings, then API Keys, then Create new. The README notes an alternative: npx -y @anyproto/anytype-mcp get-key. It also points out that after creating a key in the app you can copy a ready-made config snippet with the key already filled in, which removes the most common source of copy-paste errors. Building from source is a different toolchain: git clone, bun install, bun run build, and optionally bun link. Bun is required for development, not for use.
Where This Is the Wrong Tool
Three cases stand out. First, headless or server-side use. The default endpoint is a loopback address, and the README frames custom base URLs in terms of anytype-cli and other local ports. Nothing in the supplied material describes authentication against a remote Anytype instance, running the MCP server as a shared service, or handling multiple users' keys. If you want an assistant to touch a knowledge base that lives on a different machine, this project's documented configuration does not cover it. Second, anything that needs deterministic, auditable writes. The tool surface is generated from a spec and driven by a language model choosing which tool to call with which arguments. The README's examples are loose natural language: a due date described as in 3 days, an assignment described as assign it to me. Whether that resolves correctly depends on the model and on what the underlying API accepts, and the README does not discuss validation, confirmation steps, or dry runs. Third, anyone who wants a stable, hand-curated command set. A spec-derived tool list changes when the spec changes, and the README gives no compatibility matrix between package versions and Anytype API versions beyond the pinned Anytype-Version header in the examples.
The Alternative: anytype-cli and Direct API Calls
The README itself points at the alternative. It mentions anytype-cli on port 31012 as a case that requires ANYTYPE_API_BASE_URL. The difference in approach is the level of indirection. The CLI is a program you invoke with explicit arguments and get explicit output from; the MCP server is a program a language model invokes on your behalf, choosing arguments from a prompt. With the CLI, the mapping from intent to request is written by you and is reproducible. With the MCP server, that mapping is inferred at runtime. Neither is strictly better. The CLI cannot be driven by a conversational assistant without an extra layer, and the MCP server cannot be scripted into a cron job or a CI step in any way the README describes. A third option is calling the Anytype HTTP API directly, which the README implicitly acknowledges by linking to anyproto/anytype-api. That gives full control over the request shape, at the cost of writing and maintaining the client code that the MCP server generates for you. If your goal is repeatable automation, the direct API or the CLI is the shorter path. If your goal is exploratory, conversational manipulation of a personal space, the MCP server is the point.
Maintenance Cost, Licensing and What to Verify
The project is MIT licensed, which permits commercial and private use, modification and redistribution, subject to the usual requirement to preserve the licence text. This is a statement about the licence terms, not legal advice; consult a lawyer if the stakes justify it. The release cadence visible in the supplied material is roughly monthly, with v1.2.8 in June, v1.2.9 in June, and v1.2.10 in July, and the repository shows a push in September. That cadence suggests active work but also means the tool surface can shift between minor versions. Because the server derives its tools from the OpenAPI spec, an Anytype app update that changes the API can change what your assistant can do, and the pinned Anytype-Version header in your config is the lever you have over that. The practical maintenance burden is therefore not the MCP server itself, which you install with npx and forget, but the version alignment between three moving parts: the Anytype app, the API version header, and the package version. Anyone who pins the header and never revisits it should expect the day when it no longer matches the app. The README does not document a version compatibility table, so the only way to know is to run the server and see whether the tools you expect are present and whether calls succeed.
Editorial conclusion
Adopt anytype-mcp if you already run the Anytype desktop app on the same machine as your MCP client and want conversational control over spaces, objects, properties and tags. Do not adopt it if you need a headless server, a remote or multi-user deployment, or if you cannot keep the Anytype app running and reachable at the configured base URL. Before wiring it into anything that matters, verify three things: that the Anytype-Version header in OPENAPI_MCP_HEADERS matches the API version your installed app serves, that the default base URL http://127.0.0.1:31009 answers on your machine (or set ANYTYPE_API_BASE_URL to the port your build actually uses), and that the generated tool list matches the operations you intend to call.
Community notes