Neurons MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NEURONS_AGENT | Yes | Identifies which agent (MCP client) this server instance belongs to, e.g. "claude", "codex", "gemini" or "opencode". Passed via `-e NEURONS_AGENT=claude` (Claude Code), `--env NEURONS_AGENT=codex` (Codex), or the `env`/`environment` block of the client config. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| discoverC | Who is online, your lines (the user connects chats in the Neurons dashboard), your inbox count. Pass model/task/label to tell peers what you are doing. |
| disconnectB | Hang up your line to a handle or agent, or "all". No arguments: your only line. |
| inboxB | Unread questions, replies, reviews and handoffs for you. wait_seconds blocks until something arrives. |
| sendA | Ask (question), tell (note) or suggest a memory change (proposal) to "codex", "claude", a handle, or "all" (every chat you are connected to, for a second opinion). Messages travel only over lines the user connected in the Neurons dashboard; without one this fails. "local" asks the free local model; local_first tries it before the target. Keep it short. wait_seconds blocks for the reply. |
| replyA | Answer a message addressed to you. Only what was asked, short, with sources. Proposals: status accepted or rejected. A permission request (a question): accepted allows it, rejected denies it. |
| recallA | Search YOUR OWN knowledge: your memory files, past chats, Neurons notes and the repo. Use it to answer a peer's question. Open hits with recall_get. |
| recall_getA | Open a ref from recall ("#12", "memory:…", "session:@", "repo::"). Your own data only. |
| memory_saveA | Save, update (id) or archive (id + archive) a note in YOUR Neurons memory. Facts from a peer need source=peer and evidence of what you verified. No secrets. |
| session_readB | Without handle/native_id: list your own agent's past sessions. With one: read it (text and tool names, redacted). |
| handoff_publishB | Hand work over: goal, done, decisions (with reasons), next steps, open questions, gotchas, files, commits. |
| handoff_getB | With id: the full handoff. Without: recent handoffs, including auto snapshots of other sessions' uncommitted work (filter by repo/agent). |
| review_requestA | Ask a running agent to review a change: diff text, or base/head + files. Findings come back to your inbox. No secrets in the diff. |
| review_getB | With id: open (and claim) a review request or its result. Without: list reviews (status, mine). |
| review_submitB | Finish a claimed review: verdict, short summary, findings. The requester gets it in its inbox. |
| claimsB | Advisory edit locks so two sessions do not edit the same files. action claim (paths), release (paths, or all), list. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools have clearly distinct purposes across messaging, memory, handoffs, reviews, sessions, and edit claims. Minor potential confusion exists between discover and inbox, and between handoff_get and session_read, but the descriptions clarify the boundaries well enough.
The naming is readable and partly systematic, especially in the handoff_* and review_* families, but it mixes bare verbs (send, reply, disconnect), bare nouns (inbox, claims), and noun_verb compounds (recall_get, memory_save, session_read). The convention is not predictable across the full set.
Fifteen tools is appropriate for a multi-agent collaboration server covering messaging, memory, handoffs, reviews, sessions, and edit locks. Each tool appears to serve a distinct workflow rather than duplicating another.
The surface covers core collaboration workflows well: discovery, inbox/send/reply, memory search/save, handoff publish/read, review request/read/submit, session reading, and claims. Some minor lifecycle gaps remain, such as richer memory deletion/management beyond archiving and limited review cancellation/cleanup operations.