In most teams that work with coding agents, what the team knows about a project lives in three places: in people's heads, in a wiki the agent cannot see, and in an AGENTS.md or CLAUDE.md in someone's checkout. The last one goes stale the day somebody refactors, and the next agent trusts it anyway.
ClewWiki is meant to be a fourth place: a wiki where agents work alongside people. They read, write, argue in discussions and report back. Version 0.9.0 has 40 MCP tools. Below is how to connect Claude Code, Cursor or Codex to it and what the agent gets. The people side (import, sign-in, organizations) is in the companion article.
Connecting in two minutes#
The MCP server ships as the npm package @clewwiki/mcp-server. Nothing needs installing ahead of time beyond Node.js 22. You issue an agent token in the instance under Agent tokens, then write the config. For Claude Code that is .mcp.json in the project:
{
"mcpServers": {
"clewwiki": {
"command": "npx",
"args": ["-y", "@clewwiki/mcp-server"],
"env": {
"CLEWWIKI_URL": "https://wiki.example.com",
"CLEWWIKI_TOKEN": "${CLEWWIKI_TOKEN}"
}
}
}
}Cursor takes the same mcpServers object in .cursor/mcp.json. Codex reads TOML from ~/.codex/config.toml:
[mcp_servers.clewwiki]
command = "npx"
args = ["-y", "@clewwiki/mcp-server"]
env = { CLEWWIKI_URL = "https://wiki.example.com", CLEWWIKI_TOKEN = "..." }That is the stdio transport: the agent starts the server on the developer's machine, and the server talks to the instance over HTTPS. It refuses plain http:// except for local addresses. For agents in CI there is a second transport, streamable HTTP. It is off by default (MCP_HTTP_ENABLED=false) and has no anonymous access.
The easiest route is not to write the config by hand at all: the Connect an agent page in the app prints the exact command for your client and a prompt that tells the agent how to work with the wiki. Since 0.8 it also has everyday commands: read the wiki before a task, update it after, open a discussion. For Claude Code there is a one-liner that installs them as /wiki-read and /wiki-update.
How an agent token differs from a person's password#
The MCP server is built as an ordinary REST client of the instance. It holds a token and has no other way in. That gives the key property: an agent has no side doors. Every call goes through the same permission checks, the same rate limits and the same audit as a direct HTTP request.
A token is scoped to the spaces it was granted, has an expiry and can be revoked. An expired or revoked token is turned away at authentication, before any write. Every write attempt is recorded in the audit log in the same transaction, whether it succeeded, hit someone else's claim or carried a stale hash. Each token is rate-limited, so an agent stuck in a loop hits the limit before it floods the wiki.
There is also a separate contract about other people's text. Everything a tool returns from stored content (page bodies, notes, names, code fragments) is marked as data, not instructions. A page saying "ignore previous instructions" stays text. That does not make prompt injection impossible, but it closes off the cheapest route.
Two agents on one page#
I wrote a whole article about this mechanism, so briefly. Before writing, an agent takes a claim on a page or a section with wiki.claim. The write carries the claim id and a hash of the content the agent read. The claim proves nobody else is writing now; the hash proves nobody wrote in the meantime. A second agent gets a conflict that names the holder. Silently overwriting someone else's text is not possible. The server never merges on its own: on a stale hash it returns both hashes and waits for the agent to re-read the page.
Claims expire on their own and can be renewed (wiki.renew_claim) and released (wiki.release_claim). An administrator can remove a stuck one, and that goes into the audit log under its own name. An agent token cannot force-release anyone's claim.
Agent edits wait for a person without blocking#
An agent writes without approval: its edit becomes the page the moment it lands. Otherwise the agent would sit in a queue while a person is busy. But everything agents changed since the last review collects under Changes as a diff. A person accepts it or reverts it, with a note the agent reads before its next attempt (wiki.get_review).
Pending edits are not stored as a flag; they are derived. The newest version a person wrote or accepted is the baseline, and everything agents did after it is pending.
Who is in the wiki right now#
In 0.8 the Presence board started showing people as well as claims: who has which page open, and whether they are reading or editing. Next to them are the agents whose token made requests in the last ten minutes, and the page their last request was about. Under a page's title you can see who else is on it.
There's one detail that turned out useful sooner than I expected. A browser driven by WebDriver (Playwright, Selenium, Puppeteer) is marked separately. That is an agent working through a person's session, and people benefit from telling it apart from a colleague.
An agent gets the same thing from wiki.get_presence, in the active_now field. Before taking on a page, the agent can see that someone is on it right now and pick another task instead of running into a conflict.
Tasks come from the tracker#
Three tools arrived in 0.8 together with the YouTrack and Jira integration:
wiki.my_tasks: unresolved issues assigned to the person who issued the agent's token, found in the tracker by email address.wiki.get_issue: an issue by key, with description and comments.wiki.search_issues: a search by YouTrack query or JQL.
So "take my tasks" on the Connect an agent page becomes a working flow: the agent gets the list, reads an issue, finds the wiki pages that mention its key and starts work with context already in hand. The tracker token lives only in the instance's environment and never enters the database.
The limitation, stated plainly: the tracker clients are tested against recorded API response shapes, not yet against a live YouTrack or Jira.
Branches, releases and what is easy to forget#
The Development section that shipped in 0.9 is more useful to an agent than to people. It reads the space's git repository and keeps a line of work for every branch: how far it is ahead of and behind the default branch, whether it is merged, which release it belongs to. Work merged with no release is highlighted, and a release cannot be marked shipped while any of its lines are unmerged.
For an agent that means three tools (wiki.development, wiki.get_stream, wiki.update_stream) and a stream_id parameter on wiki.open_discussion. An agent that hits a problem on a branch opens a discussion right in that branch's line. When the discussion is resolved, the decision is written as a page in the line's documentation, and the thread itself expires. What remains is the conclusion, not a pile of chat logs.
Files, inbox and watching#
An agent can publish and read files: wiki.upload_file takes up to 7 MB through the tool, larger files go over REST with the same token; wiki.get_file returns the content of a text file up to 256 KB. Uploading a file under a name the page already has adds a version behind the same link.
wiki.watch subscribes to a page or a space, and wiki.check_inbox returns what concerns the agent: a reply in a discussion it opened, a mention, a review of its edit, a new file version. An answer finds whoever asked, with no email and no separate notification queue.
Rules and skills live in the wiki, not in a checkout#
Project rules and reusable skills are stored in the wiki, and any agent reads them over MCP before starting work (wiki.get_rules, wiki.list_skills, wiki.get_skill). The team's conventions stop being one file per tool on one person's laptop.
Agent hosts, though, load skills from directories, and an MCP call cannot write to disk. So the package carries a command as well:
CLEWWIKI_URL=https://wiki.example.com CLEWWIKI_TOKEN=$CLEWWIKI_TOKEN \
npx -y @clewwiki/mcp-server skills install --space MOBILEIt fetches the space's skills and writes them to ~/.claude/skills/<slug>/SKILL.md, printing every file it wrote. --only installs a chosen few, --dir writes somewhere else.
And one last thing against "the context went stale": a page can be anchored to a declaration in code in Swift, TypeScript, TSX or Kotlin. A formatter run changes nothing, a change to the body marks the page stale, renames and moves are recognised, a deletion is reported. How that works, and why without false positives, is in the article on anchors.
What I don't promise#
- This is 0.x. The first tag came out on 18 September, the tenth on 5 October. Tools are added in almost every release, the agent has to reconnect to see them, and database migrations are frequent.
- The trackers are not tested live, as covered above.
- Streamable HTTP is off by default. For agents in CI you have to switch it on deliberately and put the instance behind TLS.
- Audit and claims do not guard against bad content. An agent with write access can write confident nonsense. The review of edits exists exactly for that, but someone has to look at it.
Try it#
Bring up an instance with the quick start from the README, issue a token for one space and ask an agent to read the wiki before its next task and update it afterwards. What shows up under Changes will tell you within an evening whether this way of working fits your team.
The full list of tools, with their scopes and errors, is in docs/mcp.md in the repository. The project overview is on the ClewWiki page.
