Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@neurochat what's the mean uptake in the left hippocampus?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Ask questions of a brain volume in plain language; get back the figure and the
nilearncode that produced it.
A real capture from the running app, showing a real subject — one of the OASIS-1 scans the Library panel fetches. The crosshair is on the left hippocampus, resolved from the Harvard-Oxford atlas rather than from anyone's memory of where it is.
New here? QUICKSTART.md gets you from install to your first measurement in five minutes, assuming no neuroimaging background. GLOSSARY.md explains every term.
pip install . && neurochat demoTwo commands from a clone. demo opens http://127.0.0.1:8000 on a real brain —
nilearn's ICBM152 2009a template, an average of 152 real brains — with the Harvard-Oxford
subcortical atlas and the crosshair on the left hippocampus. The atlas downloads once
(~26MB) and is cached.
For a run with no network at all, neurochat demo --offline uses the bundled synthetic
phantoms instead. Those ship inside the wheel along with the vendored viewer, so the
offline path needs nothing but the install.
(Not on PyPI yet. When it is, the first command becomes pip install neurochat.)
For development, add the test extras:
pip install -e ".[dev]" && pytestChat needs ANTHROPIC_API_KEY. Without it every other control still works: clicking a
region navigates, the sliders restyle layers, and the script pane fills up — because
none of that was ever supposed to need a language model.
Related MCP server: MedVision MCP
The MCP server is the same ten tools over stdio, so your scans stay on your machine — only small JSON summaries reach the model. It also composes: inside Claude Desktop you can read subject IDs from a spreadsheet, pull each scan's regional stats, and write the results into a document, because neurochat is one capability among many rather than a separate app you have to remember to open.
Open your config:
open -e ~/Library/Application\ Support/Claude/claude_desktop_config.json(On Windows it lives at %APPDATA%\Claude\claude_desktop_config.json.) Add a neurochat
entry under mcpServers, using the absolute path to the executable:
{
"mcpServers": {
"neurochat": {
"command": "/absolute/path/to/.venv/bin/neurochat",
"args": ["mcp"]
}
}
}Then fully quit and reopen Claude Desktop — closing the window is not enough; the config is only read at launch.
The absolute path is not optional. Claude Desktop does not inherit your shell's
PATH, so a bare"command": "neurochat"fails to start with an unhelpful error even though the same command works fine in your terminal. Get the right path withwhich neurochatinside your activated environment. This is the single most common reason an MCP server silently fails to connect.
For Claude Code, one command instead:
claude mcp add neurochat -- /absolute/path/to/.venv/bin/neurochat mcpHeadless by default — screenshot() renders server-side with nilearn, so a conversation
in Claude Desktop still produces pictures and a runnable script with no browser involved.
To drive an attached viewer instead, run neurochat serve in one terminal and point the
MCP server at it:
neurochat mcp --backend http://127.0.0.1:8000Now the crosshair in the browser moves as the conversation goes, and screenshot()
captures what the user is actually looking at.
Ten tools, and only ten:
Tool | Returns |
| shape, voxel size, affine summary, detected space and how it was detected, value range, NaN count |
| atlas id, region count, the full label list |
| filtered labels with indices and centroids |
| resolved coordinates plus the space they are in |
| applied colormap, window, opacity |
| the layer stack after the operation |
| n, mean, sd, median, min, max, and every excluded voxel, counted |
| path to a difference or ratio volume, plus summary stats |
| path to a PNG, downscaled to 768px |
| path to a runnable |
Every successful call appends a nilearn/nibabel snippet to a session script. The UI
shows it live. export_script() writes a standalone file that needs only numpy, nibabel
and nilearn — not neurochat — and re-running it reproduces the numbers.
That last property is tested, not asserted: a ten-turn session is exported, run in a
fresh interpreter, and its JSON output is compared key by key against what the session
reported. See tests/test_acceptance.py::TestAcceptance3Reproducibility.
The engine always handled many volumes; the interface used to assume you were looking at one. The Library panel fixes that:
Point it at a folder. It finds every NIfTI underneath and reads headers only — no voxel data — so a directory of hundreds of scans costs nothing and loads nothing. Each entry shows its grid and its detected space, so you can see which scans will refuse region names before you commit to any of them.
Click a scan to inspect it. It loads and becomes the only thing on screen, rather than the twentieth layer on a stack.
Tabulate one region across every scan. Pick a region, hit the button, and get a table of per-scan statistics — clickable rows jump to that subject. It emits a single loop into the session script, not one copy per scan, and it reproduces on re-run.
None of it involves the model. The LLM counter stays at zero throughout.
Two buttons load real cohorts:
MRI cohort — 12 subjects from OASIS-1 (structural grey-matter density maps).
All of them carry sform_code=2, so the whole cohort lands on the space-assertion
path, which is what a lot of real normalised data actually looks like.
PET cohort — 8 subjects from OpenNeuro ds004054, real [18F]FDG SUV maps. Only
the ~4MB derivative per subject is downloaded, not the 500MB dataset.
The PET files need a header repair, and neurochat says so every time it hands them to
you. They ship on the SPM MNI 1mm grid but declare scanner space with x/y origins
offset by exactly one field of view — with the shipped affine, 0% of every atlas
region falls inside the brain; with the canonical affine, 44-60% does, the shortfall
being PET's axial field of view clipping the inferior brain. The untouched downloads
are kept alongside as *_original.nii.gz, and a test asserts the shipped affine really
is broken, so if OpenNeuro fixes it upstream the repair gets removed rather than
silently kept.
An LLM asked for "the coordinates of left entorhinal cortex" will produce a confident, wrong number. So the model never emits one.
Region names resolve through a lookup table measured from the loaded atlas volume — centroids computed from the actual mask, not recalled.
Only exact matches resolve. "left hippocampos" is one edit from a real label, which is
exactly why accepting it is dangerous: it returns the three closest real labels and asks.
The centroid is used only when it lands inside the structure. Hippocampus is curved enough that its centre of mass can sit in the ventricle next door, so each region also carries the in-region voxel nearest the centroid, and the response says when it was used.
Every location states its space: MNI152NLin6Asym, MNI152NLin2009cAsym, native, or
voxel[i,j,k].
A volume whose space cannot be established refuses named regions and names the missing metadata. Grid geometry that happens to match a known template is reported as a hint and never used to decide — that is how a scanner-native volume quietly acquires MNI region labels.
That refusal is never a dead end. When geometry suggests a template, the response names
the one argument that resolves it and the UI offers it as a single button. Accepting is
recorded as user_override: the software still refuses to guess, but you can decide in
one click, and the provenance says it was you.
$ neurochat check --atlas harvard-oxford-sub
Loading atlas 'harvard-oxford-sub'…
harvard-oxford-sub: 21 regions in MNI152NLin6Asym at 2.0mm
resolve('Left Hippocampus') -> Left Hippocampus at [-24.9, -22.2, -14.3] MNI152NLin6Asym
2036 voxels, 16288 mm^3, centroid inside region: True
resolve('Left Hippocampux') -> did-you-mean ['Left Hippocampus', 'Left Thalamus', 'Left Putamen']
Grounding works: names resolve from the atlas, typos ask instead of guessing.This paradigm is not novel in general. It is novel for volumetric human neuroimaging. Naming your neighbours accurately is a credibility signal; pretending to be first is a credibility disaster.
Omega / napari-chatgpt (Royer lab, CZ
Biohub; Nature Methods, June 2024) is the closest published analogue: a conversational
LLM agent as a napari plugin that processes and analyses images, corrects its own coding
mistakes, and chains stateful queries. The team has since moved to napari-mcp for
broader LLM compatibility. We take the chained stateful queries and the table-returning
tools. We do not take the one thing that makes Omega work — Omega executes arbitrary
generated Python. That is defensible for a research demo and indefensible for a tool
pointed at patient-derived scans, so our surface is a fixed ten tools (see Hard Rule R3).
AllenNeuralDynamics/neuroglancer-chat
is the closest neuro analogue: an agent interface for Neuroglancer. We copied its design
outright — a compact tool_trace on every response, a bounded /debug/tool_trace
endpoint, cached result tables that follow-ups operate on, and the rule that clicking a
row navigates the viewer without a new LLM call. Its domain is EM and connectomics
volumes, not NIfTI in MNI space. That is our opening.
NLI4VolVis (2025) is the interaction-design precedent for natural-language volume visualisation, and we did not redesign its four-pane layout. Its two reported failure modes are our design constraints: LLM latency disrupting interactive flow (addressed by making every deterministic action bypass the model entirely, and by pushing viewer commands over a WebSocket as each tool completes, so the crosshair moves before the prose finishes streaming), and limited domain coverage from predefined tools (addressed by injecting the atlas's real label vocabulary into context at load time, so the model matches against strings that exist).
NeuroAgent (arXiv, May 2026) automates preprocessing across sMRI, fMRI, dMRI and PET
with a hierarchical Generate-Execute-Validate engine wrapping dcm2niix and FreeSurfer.
That territory is claimed, and it is a swamp of 10GB installs and hour-long jobs.
Preprocessing is a Non-Goal here. Ask neurochat to run recon-all and it will decline
and point you at NeuroAgent, fMRIPrep, or dcm2niix by name.
Niivue renders. We do not write a viewer. Niivue
ships no UI outside the canvas by design, which is exactly the integration point; v0.69.0
is vendored into web/vendor/ (BSD-2-Clause) so the app needs no CDN and no build step.
The delta: nothing equivalent exists for volumetric human neuroimaging — NIfTI volumes,
MNI space, standard atlases, MRI and PET — and nothing in the list above emits reproducible
nilearn code as a first-class output.
GLOSSARY.md explains every term this project uses — voxel, volume, MNI, template, atlas, mask, resampling — building up from "what is a scan" rather than assuming the vocabulary. Written for someone with no background in the field.
No preprocessing. No statistics or inference. No arbitrary code execution. No custom viewer. No clinical claims. No accounts or cloud storage. These are enforced, not aspirational — read LIMITATIONS.md before using this for anything.
Ask for a t-test and you get a refusal that names nilearn.glm and FSL randomise,
plus the suggested code written into your script as a comment, never executed.
The default demo runs on real data. nilearn ships the ICBM152 2009a template — an average of 152 real brains — and neurochat pairs it with the real Harvard-Oxford atlas. Note what happens when it does: the template is a different MNI152 variant from the atlas, and the tool says so rather than quietly absorbing the few-millimetre disagreement.
Everything in sample_data/ is synthetic, generated by scripts/make_sample_data.py,
with no subject-derived or third-party material. It exists so the tool — including region
resolution, did-you-mean, and honest NaN accounting — works offline with zero downloads:
File | What it is |
| structural-like phantom on the FSL MNI152 4mm grid, with a BIDS sidecar |
| PET-like uptake with a deliberate slab of NaN dropout |
| the same phantom with localised change, for |
| identical grid with |
| 16 geometric regions, not anatomy (see LIMITATIONS.md) |
Real atlases — Harvard-Oxford, AAL, Schaefer — are fetched on demand through nilearn and cached. They are not redistributed here because their licences are not ours to relicense.
pip install -e ".[dev]"
python scripts/make_sample_data.py # regenerate sample data (deterministic)
pytest # 103 tests; the seven acceptance tests are in tests/test_acceptance.py
pytest -m "not network" # skip the tests that fetch a real atlas
neurochat check # is atlas grounding working on this machine?MIT — see LICENSE.
Third-party components keep their own terms, listed in NOTICE.md: vendored Niivue is BSD-2-Clause, and atlases fetched at runtime are not redistributed here. Harvard-Oxford in particular ships with FSL under a licence that restricts commercial use — check it before publishing work that used it.
Voxelwise difference or ratio of two loaded volumes; adds the result to the session.
Arithmetic, not inference. The output is not a statistical map and carries no significance of any kind — describe it as a difference image, nothing more.
Args: a: First volume (the minuend / numerator). Defines the output grid. b: Second volume. Resampled onto a's grid if the grids differ. method: "difference" or "ratio". name: Handle for the result volume.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes | ||
| name | No | ||
| method | No | difference |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: resampling of volume b onto a's grid if grids differ, and that the result is added to the session. Without annotations, this is valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a clear front-loaded purpose, followed by precise parameter explanations. Every sentence adds value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently covers the tool's behavior for a neuroimaging context, but could be slightly more complete by noting the output's data type or that it becomes available for subsequent operations. However, the absence of an output schema is mitigated by the 'adds to session' statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite zero schema description coverage, the Args section provides full semantic meaning for all four parameters: 'a' is minuend/numerator and output grid, 'b' is second volume with resampling note, 'method' lists options, and 'name' is a handle. This completely compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs voxelwise difference or ratio between two volumes and adds the result to the session. It specifies 'Arithmetic, not inference,' effectively distinguishing it from statistical tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives important usage guidance by saying the output is not a statistical map and should be described as a difference image. It does not explicitly mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write the whole session as a standalone runnable .py and return its path.
This is the deliverable. It needs only numpy, nibabel and nilearn — not neurochat — and re-running it reproduces the numbers reported in this conversation.
Args: path: Where to write the script, e.g. "~/analysis/session.py".
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the side effect (writing a file) and return value (path), along with dependencies and reproducibility. This is transparent for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences plus an Args block, no redundancy, and front-loaded with the key action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers purpose, parameter, and usage. It could mention overwrite behavior, but it is sufficiently complete for the agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides meaningful context for the 'path' parameter with an example ('~/analysis/session.py'), explaining where to write the script. This adds value beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write') and the resource ('whole session as a standalone runnable .py and return its path'). It distinguishes from sibling tools that load, navigate, or display data, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is the deliverable and specifies dependencies (numpy, nibabel, nilearn), implying when to use. It does not explicitly exclude alternatives or compare to siblings, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search the loaded atlas's regions, with voxel counts and centroids.
Args: query: Substring or fuzzy filter, e.g. "hippocampus". Omit for everything. limit: Maximum rows to return (capped at 200).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the tool returns voxel counts and centroids, and imposes a 200-row cap. It does not mention error states or permissions, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-paragraph docstring with clear Args section. Every sentence adds value, no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description notes return includes voxel counts and centroids, and covers limiting behavior. It lacks details on ordering or error handling, but is sufficient for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds full semantic meaning: query is a substring/fuzzy filter, limit is capped at 200 with default 50. This goes well beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists or searches atlas regions with voxel counts and centroids, using specific verb and resource. It distinguishes from siblings like load_atlas (loading) and roi_stats (statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the query parameter (substring/fuzzy filter) and that omitting it returns everything. It also notes the limit cap at 200. However, it lacks explicit contrast with sibling tools like roi_stats or compare_volumes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load an atlas and return its full label list.
The label list is what grounds every later region name — match user phrasing against these strings, not against your own knowledge of neuroanatomy.
Args: atlas_name: One of demo-16, harvard-oxford-sub, harvard-oxford-cort, aal, schaefer-100. Non-bundled atlases are fetched once via nilearn and cached.
| Name | Required | Description | Default |
|---|---|---|---|
| atlas_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that non-bundled atlases are fetched and cached, which is relevant behavioral context. No annotations are provided, so the description covers the safety profile (read-only load). It could be more explicit about read-only nature but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus argument details, with each sentence contributing purpose, usage importance, and parameter details. It is front-loaded with the core action and has no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and no output schema, the description covers what is returned (full label list) and why it matters. It is complete for an agent to understand and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), but the description lists all valid values for 'atlas_name' and explains caching behavior for non-bundled atlases. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Load an atlas and return its full label list,' specifying the verb and resource. It distinguishes from siblings like 'load_volume' by focusing on atlases and labels, and explains the role of the label list in grounding region names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use the tool: before referencing regions, emphasizing that labels from this tool must be used over the agent's own knowledge. It lists valid atlas names. However, it does not explicitly mention when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load an already-preprocessed NIfTI volume (MRI, PET) into the session.
Returns shape, voxel size, affine summary, detected space and how it was detected, value range, and NaN count. No preprocessing is performed on the file.
Args: path: Path to a .nii or .nii.gz file. name: Short handle for later calls. Defaults to the filename stem. space: Assert the template space when the header does not record one, e.g. "MNI152NLin6Asym". Recorded as your assertion, not an inference.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| path | Yes | ||
| space | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return values (shape, voxel size, etc.) and states no preprocessing is performed. Lacks mention of side effects on session state, but adequately covers safety for a load operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise paragraph covering purpose and return info, followed by clear argument descriptions. Every sentence is informative and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description fully covers inputs, expected outputs, and key behaviors (no preprocessing, space assertion). No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, description thoroughly explains each parameter: path format, name default, and space assertion semantics. Adds significant value beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it loads a preprocessed NIfTI volume (MRI, PET) and returns detailed info. Distinguishes from sibling 'load_atlas' which loads atlases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies that the volume must be already-preprocessed, but does not provide explicit guidance on when to use versus alternatives like compare_volumes or roi_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stack one loaded volume on top of another and return the layer order.
Display only — no registration is performed. If the two volumes are not already aligned, say so rather than implying the overlay means anything.
Args: volume: The layer to put on top. on_top_of: The base layer. Defaults to the current bottom layer. opacity: Opacity of the top layer, 0.0 to 1.0.
| Name | Required | Description | Default |
|---|---|---|---|
| volume | Yes | ||
| opacity | No | ||
| on_top_of | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: display-only, no registration, alignment requirement. No annotation provided so description carries burden, and it does well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with core action, followed by essential warnings and parameter list. Every sentence serves a purpose; mild repetitiveness in param docs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers operation, return value, behavioral boundaries, and parameter details. Lacks mention of error handling or result format, but adequate for visualization tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates by explaining each parameter's role, defaults, and constraints (e.g., opacity range). Adds clarity beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'stack' and resource 'loaded volumes', and distinguishes from siblings like compare_volumes by emphasizing display-only and no registration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when not to use (if volumes unaligned) and explains defaults, but could be more explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Descriptive statistics inside an atlas region or a mask file.
Returns n_voxels, mean, sd, median, min, max, and an explicit count of every excluded voxel. Report those exclusion counts in your answer — they are not a footnote. There is no inference here: no test, no p-value, no threshold.
Args: volume: Volume to measure. Defaults to the most recently loaded. region_label: Atlas region name. Mutually exclusive with mask_path. mask_path: Path to a binary mask NIfTI. Mutually exclusive with region_label. exclude_zeros: Drop exactly-zero voxels. Off by default; zeros are counted and included, because treating zero as "no data" is an assumption.
| Name | Required | Description | Default |
|---|---|---|---|
| volume | No | ||
| mask_path | No | ||
| region_label | No | ||
| exclude_zeros | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it returns specific statistics, emphasizes reporting exclusion counts, states no inference is performed, and details the exclude_zeros parameter implications. This surpasses the need for annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first line states purpose, then lists return values, followed by parameter details. No unnecessary words, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with no output schema, the description covers all necessary aspects: return values, parameter constraints, default behavior, and usage caveats. It is fully complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains volume defaults to the most recently loaded, clarifies mutual exclusivity of region_label and mask_path, and describes exclude_zeros default and rationale. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns descriptive statistics (n_voxels, mean, sd, median, min, max) inside an atlas region or mask file. It explicitly distinguishes from sibling tools like compare_volumes by stating no inference is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool (for descriptive statistics) and what it does not do (no inference). It also explains mutual exclusivity of region_label and mask_path, and notes the default volume. However, it does not explicitly compare to alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the current view as a downscaled PNG and return the image and its path.
Uses the live Niivue canvas when a browser viewer is attached, otherwise renders the same layer stack server-side with nilearn. The response says which one ran.
Args: filename: Optional name for the PNG inside the session's temp directory.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses rendering behavior (live canvas vs. server-side) and notes the response indicates which method ran. It lacks details on downscaling ratio or behavior on empty views, but overall provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences plus one line for the parameter, with the main action front-loaded. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter, no output schema, and no annotations, the description sufficiently covers the tool's behavior: it captures a view, returns an image and path, and explains rendering modes. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by explaining the filename parameter: 'Optional name for the PNG inside the session's temp directory.' This clarifies the parameter's purpose beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Capture the current view as a downscaled PNG and return the image and its path.' It uses a specific verb (capture) and resource (current view as PNG), clearly distinguishing it from sibling tools that load or process data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a screenshot of the current view is needed, mentioning two rendering modes (browser vs server-side). However, it does not explicitly state when to use or not use this tool, nor does it name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set colormap, intensity window and opacity for one layer.
Args: volume: Layer to restyle. Defaults to the most recently loaded. colormap: gray, hot, cool, viridis, inferno, magma, plasma, jet, bone, ... min: Low end of the display window (does not alter the data). max: High end of the display window. opacity: 0.0 to 1.0.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | ||
| min | No | ||
| volume | No | ||
| opacity | No | ||
| colormap | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clarifies that min/max 'does not alter the data,' indicating non-destructive behavior. It doesn't detail other traits like permission needs or reversibility, but the behavior is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 7 lines with a clear Args structure. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and non-destructive nature. It lacks detail about return values or confirmation of changes, but given the simple display operation, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining each parameter: colormap examples, min/max meaning, opacity range, and volume default. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'set colormap, intensity window and opacity for one layer,' specifying the verb and resource. It uniquely handles display settings, distinguishing from siblings like load_volume or navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Defaults to the most recently loaded' volume, implying typical use. However, it does not explicitly state when not to use or provide alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0compare_volumesexport_scriptlist_regionsload_atlasload_volumenavigateoverlayroi_statsscreenshotset_displayEach tool has a clearly distinct purpose: loading atlases and volumes, listing regions, navigating, display settings, overlays, ROI statistics, volume arithmetic, screenshots, and script export. No two tools could be confused.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., load_atlas, list_regions, compare_volumes). Even 'screenshot' is a common noun-as-verb, fitting the pattern. No mixing of styles.
With 10 tools covering loading, exploration, visualization, statistics, comparison, and export, the set is well-scoped for neuroimaging analysis. Each tool earns its place without unnecessary redundancy.
The tools cover core workflows: data loading, region inspection, navigation, display, statistics, and script export. Minor gaps exist, such as missing histogram or filtering capabilities, but the surface is sufficient for reproducible exploration.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Reproducible benchmarks and reliability evidence for agent tools.
Connect AI clients to biomedical data and tools.
Sentiment, toxicity, entity extraction, PII, translation, summary, QA, fraud scoring, safety audit.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AyushXRane/neurochat'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
