For agents
coLab over MCP
Connect Claude, or any assistant that speaks the Model Context Protocol, to your projects — 44 tools over one URL, with nothing to install.
What this is
MCP is how an AI assistant is handed tools rather than told to read documentation. Point one at the URL below and it can search your workspace, open a project, pick up a task, read what reviewers pinned on a build, and write back — as you, reaching exactly the projects you can reach and nothing else.
Server URL | https://colab.neurasense.io/api/mcp |
Transport | Streamable HTTP. Stateless — every call is one request, so there is no session to keep alive and nothing to reconnect. |
Auth | An API token, sent as Authorization: Bearer colab_pat_… — the same credential the HTTP API takes. Make one on your account page. |
This is not a wrapper around the public API. It runs inside coLab and calls the same internal services the app itself does, which is why some tools do in one call what would otherwise be four, and why colab_search can reach across everything at once.
Connecting
Every client wants the same three things: the URL, the transport, and an Authorization header. What differs is where you type them.
Claude Code
claude mcp add --transport http colab https://colab.neurasense.io/api/mcp \
--header "Authorization: Bearer $(cat ~/.colab/token)" \
--scope user
--scope user makes it available in every project rather than one repo. Run /mcp afterwards to confirm it connected. Note that the token is written into your config as plain text, so treat that file the way you would any other credential store.
VS Code
Command Palette → MCP: Open User Configuration, or a .vscode/mcp.json in a workspace:
{
"inputs": [
{ "type": "promptString", "id": "colab-token",
"description": "coLab API token", "password": true }
],
"servers": {
"colab": {
"type": "http",
"url": "https://colab.neurasense.io/api/mcp",
"headers": { "Authorization": "Bearer ${input:colab-token}" }
}
}
}
Asking for the token as an input keeps it out of the file, which matters if the file is in a repository.
Anything else
Give it the URL, choose Streamable HTTP, and add the Authorization header. To check a connection by hand:
curl -X POST https://colab.neurasense.io/api/mcp \
-H "Authorization: Bearer $COLAB_TOKEN" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
What it may touch
An agent connected this way is you. It sees the projects you can open and nothing else — the same checks the app runs when you click, because both go through the same code underneath. A project you cannot reach answers as though it does not exist.
Scope is the other half. A token is minted read or write, and a read-only connection is not merely refused when it tries to change something: the 27 writing tools are never offered to it, so they do not appear in its list at all. If you want an assistant that can look but not touch, mint a read token and connect with that.
Tokens can be revoked at any time from your account page, which stops the next call rather than the next cleanup.
What the agent is told
Every client is handed this on connect, before it calls anything. It is reproduced here in full — worth reading, because it is the part that decides whether an assistant uses coLab well or badly.
coLab is a project workspace: projects hold tasks, milestones, notes, a
decision log, and previews — builds under review that people pin notes on.
Finding things: use `colab_search` when you do not already have an id. It covers every
kind of object at once and accepts `@Name` (or `@me`) to narrow to one person.
Reading: prefer the composed tools. `colab_project_brief` returns a project with its
milestones, open tasks and recent decisions in one call, and `colab_get_task` returns a
task with its comment thread, links and attachments. Reach for the list tools when you
want to scan across projects rather than open one.
Mentions: writing `@someone` is how work reaches a person, and `@somehandle` is how it
reaches an agent — the mention is what triggers a run. Both are matched against a fixed
list when the text is saved, and anything that does not match is kept as ordinary prose:
nobody is notified, nothing runs, and no error is reported. So check
`colab_list_mentionable` first and use its `mention` field verbatim; a person is named by
their display name and an agent by its handle, which are different fields.
`colab_project_brief` already carries the same list.
Mentions resolve in a task's details, a task comment, a note, and a chat message. They do
NOT resolve in a reply on a review pin — an `@` written through
`colab_reply_to_thread` is shown to the reviewer as literal text and reaches nobody.
Reviews: a pin is a note a reviewer left on a running build.
`colab_list_preview_threads` with `status: "open"` is what a build still owes somebody.
`colab_get_preview_thread` returns the screenshot the reviewer's browser captured, so
you can see the thing being complained about. Replying is visible to the reviewer on the
build itself, so write for them, not for the team.
Opening a preview: use `colab_preview_review_link`, and never give out `hosted_url`. That
field is only where a build's files answer — it sits on an origin that receives no coLab
session, so it is refused without a ticket, and even when it loads it shows the bare
build with no overlay, which is where the pinned notes are. The review link mints the
ticket and turns the overlay on; `at` lands on a particular page.
`colab_get_preview_thread` already returns `open_url` for its own pin. Treat a review
link as a credential: anyone holding it can comment on the build.
Failures come back with a machine-readable `code`: `not_found` (no such row, or not one
this account can reach), `forbidden`, `invalid_request`, `insufficient_scope`. A
read-only connection simply does not list the tools that write.
Worth knowing
Mentions have to match exactly
Writing @someone is how work reaches a person and @somehandle is how it reaches an agent — but a mention that matches nobody is kept as ordinary text. Nobody is notified, no agent runs, and nothing reports a problem. People are named by their display name and agents by their handle, which are different fields. Use colab_list_mentionable and copy its mention value.
Review links are credentials
colab_preview_review_link hands back a link that lets whoever holds it comment on the build, with no account. That is what makes it useful and what makes it worth handing out deliberately. Rotating a preview’s link revokes every copy already sent.
A build’s own URL is not a way in
An uploaded build is served from its own origin, which no coLab session reaches, and opening it directly shows the bare page with no review overlay — so the pinned notes are invisible. Anything meaning “go and look at the preview” should be the review link.
Failures are machine-readable
A tool that fails comes back with a code — not_found, forbidden, invalid_request, insufficient_scope — the same vocabulary the HTTP API uses, so an assistant that has learned one has learned the other.