How do I use millimap-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@millimap-mcp list the cell-type annotations in my dataset" 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.

millimap-mcp

Official

by milliomics

Overview Schema Related Servers Score Discussions

Python

Local

millimap-mcp

MCP (Model Context Protocol) server that lets Claude Desktop read the active MilliMap session — its dataset, clusters, cell-type annotations, marker genes, regions of interest — and drive analyses inside the viewer from chat.

How it works

┌──────────────────┐       writes        ┌──────────────────────────┐
│  MilliMap        │  ──────────────▶    │  ~/.millimap/            │
│  (desktop app)   │     every 3s        │  mcp_session.json        │
└──────────────────┘                     └──────────────────────────┘
                                                    │ reads
                                                    ▼
                                         ┌──────────────────────────┐
┌──────────────────┐     stdio MCP       │  millimap-mcp            │
│  Claude Desktop  │  ◀───────────────▶  │  (this package)          │
└──────────────────┘                     └──────────────────────────┘

MilliMap writes a snapshot of its current session to ~/.millimap/mcp_session.json every few seconds. This MCP server is launched by Claude Desktop as a stdio subprocess; it reads the snapshot and exposes it to Claude as MCP resources and tools.

Related MCP server: BioNext-mcp

Prerequisites

MilliMap installed and runnable — see milliomics/MilliMap.
Claude Desktop — download from anthropic.com.
Python 3.10+ with pip.

Install — into your existing MilliMap environment

Important: install millimap-mcp into the same Python environment you use to run MilliMap. That way the resulting millimap-mcp script lands in that env's bin/ (or Scripts\ on Windows), and Claude Desktop finds it automatically when you activate the env.

If you set up MilliMap with conda (the recommended path)

# 1. Activate the MilliMap env FIRST — this is the step people miss.
conda activate millimap

# 2. Clone this repo somewhere convenient.
git clone https://github.com/milliomics/millimap-mcp.git
cd millimap-mcp

# 3. Install into the activated env.
pip install -e .

If you set up MilliMap with pip (no conda)

Use the same Python you use to launch MilliMap. The safest invocation is to spell out the interpreter explicitly:

git clone https://github.com/milliomics/millimap-mcp.git
cd millimap-mcp

# Replace this with the python you use for MilliMap:
/path/to/your/python -m pip install -e .

# e.g.:
# /usr/local/bin/python3.11 -m pip install -e .
# or:
# /Users/you/venvs/millimap/bin/python -m pip install -e .

Verify the install

After install, the millimap-mcp script should be on your PATH (when the env is activated):

which millimap-mcp           # macOS / Linux
where millimap-mcp           # Windows

You should see a path under your MilliMap env, e.g.:

conda: /Users/<you>/anaconda3/envs/millimap/bin/millimap-mcp
venv: /Users/<you>/venvs/millimap/bin/millimap-mcp
Windows conda: C:\Users\<you>\anaconda3\envs\millimap\Scripts\millimap-mcp.exe

Keep that path handy — you'll paste it into Claude Desktop's config in the next step (or just use the bare name millimap-mcp if Claude Desktop sees the same PATH you do).

Wire it up to Claude Desktop

Open Claude Desktop's config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

Create the file if it doesn't exist. Add (merge into any existing mcpServers object):

{
  "mcpServers": {
    "millimap": {
      "command": "millimap-mcp"
    }
  }
}

Use an absolute path if `millimap-mcp` isn't on Claude Desktop's PATH

Claude Desktop launches subprocesses with its own PATH, which may not include your conda env's bin/. If you get "command not found" / "spawn ENOENT" after restarting Claude, swap the bare command for the absolute path you got from which millimap-mcp above:

{
  "mcpServers": {
    "millimap": {
      "command": "/Users/<you>/anaconda3/envs/millimap/bin/millimap-mcp"
    }
  }
}

On Windows, double-escape backslashes (JSON requires it):

{
  "mcpServers": {
    "millimap": {
      "command": "C:\\Users\\<you>\\anaconda3\\envs\\millimap\\Scripts\\millimap-mcp.exe"
    }
  }
}

Then fully quit + relaunch Claude Desktop (the window-close X is not enough — quit from the menu bar / system tray).

In Claude Desktop's tools menu (plug icon in the message composer) you should now see millimap. Toggle it on.

What Claude can see

Resources (read-only context):

millimap://session — dataset name, cell/gene counts, assay, cluster column
millimap://clusters — cluster IDs and sizes
millimap://annotations — cluster → cell-type labels set by the scientist
millimap://markers — top marker genes per cluster
millimap://rois — regions of interest saved in the session
millimap://analysis_cards — workspace result cards (summaries only — use get_analysis_card for the full payload)

Read tools (read the snapshot, no side effects):

get_cluster_markers(cluster_id, top_n) — markers for one cluster
genes_for_cell_type(cell_type) — "what genes mark T cells?"
search_genes(query, limit) — find which cluster a gene marks
list_rois() — enumerate saved ROIs
list_analysis_cards() — workspace result cards (summaries)
get_analysis_card(card_id, max_rows) — full payload of one card including its DataFrame

Write tools (drive MilliMap's analysis library + UI):

run_clustering(resolution, n_neighbors) — re-cluster the dataset
find_markers(groupby, method) — run rank_genes_groups
annotate_cluster(cluster_id, label) — assign a cell-type label
score_gene_signature(genes, score_name) — score a gene set across cells
apply_qc_filter(min_genes, max_genes, min_counts, max_mito_pct) — QC filter
run_millimap_tool(tool_name, tool_args_json) — escape hatch for any of MilliMap's 30+ analysis tools (DE, GO enrichment, neighborhood enrichment, co-occurrence, Ripley, doublet detection, dotplot/heatmap/violin, etc.)

Write tools require MilliMap to be running with a dataset loaded. They POST to a local HTTP endpoint (127.0.0.1, ephemeral port) served by the viewer; the port is discovered via ~/.millimap/mcp_control.json.

Available Tools

12 tools

annotate_clusterA

Set a cell-type annotation on a cluster in the running MilliMap session.

The label appears in MilliMap's annotation panel and is written back to the session snapshot — use this when you've figured out what a cluster is.

Args: cluster_id: Cluster identifier as shown in MilliMap (e.g. "Cluster 3", "1"). label: Cell-type name (e.g. "CD8+ T cell", "fibroblast", "doublet").

ParametersJSON Schema

Name	Required	Description	Default
`cluster_id`	Yes
`label`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the label is written back to the session snapshot, indicating a side effect. Although no annotations exist, this provides adequate transparency for a simple annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, starting with the primary purpose, and each sentence is informative without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two simple string parameters, the description covers purpose, usage context, and parameter examples sufficiently, making it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description compensates by providing example values for both parameters (e.g., 'Cluster 3', 'CD8+ T cell'), adding meaningful context beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (set a cell-type annotation) and the resource (a cluster in a MilliMap session), distinguishing it from sibling tools like run_clustering or find_markers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'use this when you've figured out what a cluster is,' providing clear context for when to use the tool, though it does not discuss when not to use it or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

apply_qc_filterA

Apply QC filters to the active dataset in MilliMap.

Replaces the active adata with the filtered subset and re-renders. The original can be restored via the in-app QC controls.

ParametersJSON Schema

Name	Required	Description	Default
`min_genes`	No
`max_genes`	No
`min_counts`	No
`max_mito_pct`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool replaces the active dataset (destructive action) and that re-rendering occurs, plus restoration via in-app controls. It could add details about permissions or side effects but is fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with purpose, and every sentence adds value. No redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description lacks parameter context for all four parameters. Given zero schema description coverage, the description should compensate but fails to do so, leaving critical information missing for proper tool usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning beyond parameter names and defaults. It does not explain what min_genes, max_genes, min_counts, or max_mito_pct represent, leaving the agent without necessary context for proper parameter selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool applies QC filters to the active dataset in MilliMap, specifying the action and resource. It distinguishes from sibling tools that perform clustering, marker finding, or other analyses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the tool replaces the active adata with the filtered subset and mentions restoration via in-app controls. It provides clear context of use but does not explicitly state when not to use 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.

find_markersA

Run rank_genes_groups in MilliMap to find marker genes per cluster.

After this completes, the MilliMap snapshot refreshes with the top markers per cluster — subsequent calls to get_cluster_markers or genes_for_cell_type will see them.

Args: groupby: obs column to group by. Default 'clusters'. method: 'wilcoxon' (default), 't-test', or 'logreg'.

ParametersJSON Schema

Name	Required	Description	Default
`groupby`	No		clusters
`method`	No		wilcoxon

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, description carries full burden. It reveals a side effect (snapshot refresh) but omits details on idempotency, authorization, or state requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise with a clear first sentence and structured Args, but the side-effect sentence could be integrated to reduce length slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Coverage is adequate for a simple tool with output schema; adds side-effect context and param details. Missing prerequisites (e.g., needing clusters) are a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description compensates with clear 'Args' listing allowed values and defaults, though method lists only three options while schema allows any string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it finds marker genes per cluster using rank_genes_groups in MilliMap. The mention of subsequent calls to get_cluster_markers or genes_for_cell_type distinguishes it from those retrieval tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies usage by noting that after completion, other tools will see the results, but lacks explicit direction on when to use versus alternatives like run_clustering.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

genes_for_cell_typeA

Find which clusters are annotated as a given cell type, with their markers.

Use this when the user asks things like "what genes are for T cells" — we find every cluster labelled with that cell type and return their marker genes.

ParametersJSON Schema

Name	Required	Description	Default
`cell_type`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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 clarifies that the tool finds clusters labeled with that cell type and returns marker genes, which is transparent. No side effects or additional behaviors are relevant.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first clearly states the purpose, second provides a usage example. No redundant information; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and an output schema, the description covers purpose, usage, and parameter meaning completely. No additional information is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'cell_type' has 0% schema description coverage, but the description adds meaning by explaining it as a given cell type and giving an example ('T cells'). This compensates adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds clusters annotated with a given cell type and returns their marker genes. It uses specific verb 'Find' and resource 'clusters annotated as a given cell type', and the functionality is distinct from sibling tools like find_markers and get_cluster_markers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this when the user asks things like "what genes are for T cells"', providing a clear use case. It does not explicitly mention when not to use or alternatives, 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.

get_analysis_cardA

Fetch the full payload of one analysis result card, including its underlying DataFrame (up to max_rows rows, default 50).

Use this to inspect the actual numbers behind a card — e.g. the differential expression table, spatial autocorrelation p-values, neighborhood enrichment z-scores — so you can reason over the result.

Args: card_id: The id field from list_analysis_cards (a hex token). max_rows: Max rows of the DataFrame to include (1–500, default 50).

ParametersJSON Schema

Name	Required	Description	Default
`card_id`	Yes
`max_rows`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description discloses key behavioral traits: it returns a DataFrame up to max_rows rows (default 50). It does not mention any side effects, but as a read operation, the disclosure is adequate. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. It starts with a clear one-sentence purpose, followed by examples and parameter explanations. No redundant or extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and the presence of an output schema, the description adequately covers the return value (DataFrame with rows). It provides sufficient context for an agent to use the tool effectively, though it could briefly mention that the output schema details are available.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description adds essential meaning: card_id is a hex token from list_analysis_cards, and max_rows limits rows (1–500, default 50). This goes well beyond the schema's minimal type info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it fetches the full payload of one analysis result card, including the underlying DataFrame. It distinguishes from siblings (e.g., list_analysis_cards) by focusing on fetching a single card's full data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: it is used to inspect the actual numbers behind a card (e.g., tables, p-values). It mentions using the id from list_analysis_cards but does not explicitly exclude when not to use this tool or mention 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.

get_cluster_markersB

Return top marker genes for a specific cluster.

Args: cluster_id: Cluster identifier as a string (e.g., "0", "1", "CD8_T"). top_n: Number of top markers to return (default 10, max 15).

ParametersJSON Schema

Name	Required	Description	Default
`cluster_id`	Yes
`top_n`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It only states the action without disclosing side effects, ordering, or limitations. Output schema exists but is not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus parameter list, no filler. Efficient and front-loaded with purpose. Could be slightly more structured, but very concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool and presence of output schema, the description covers the basics. However, it lacks context about when to use this vs sibling tools, which is a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds meaning: explains cluster_id as a string with examples and top_n with default and max. This significantly helps the agent beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Return top marker genes for a specific cluster,' specifying verb and resource. However, it does not differentiate from sibling tools like find_markers, which may have similar purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like find_markers or genes_for_cell_type. The description does not mention when-not or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_analysis_cardsA

List the analysis result cards visible in MilliMap's workspace sidebar.

Same data as the millimap://analysis_cards resource — returns an array of summaries. Use get_analysis_card to load the full payload for a specific card.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it returns an array of summaries, but does not mention any side effects, ordering, pagination, or other behavioral characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words, front-loading the main purpose and then providing a sibling reference.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and no parameters, the description is mostly complete. It could optionally mention if there is any limit or pagination, but not necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters and schema description coverage is 100%. With no params, the description does not need to add parameter info, and the baseline is 4 per rubric.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists analysis result cards visible in MilliMap's workspace sidebar, and distinguishes from the sibling tool get_analysis_card by noting that the latter loads the full payload for a specific card.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It mentions that the data is the same as the millimap://analysis_cards resource and suggests using get_analysis_card for full details, providing context on when to use this tool versus alternatives, though it does not explicitly list scenarios to avoid.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_roisA

List all ROIs saved in the current MilliMap session.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It correctly implies a read-only listing operation but does not disclose potential session dependencies or output format limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence with no wasted words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately explains what the tool does given the simple nature of listing all ROIs in the current session. However, it does not mention what properties are returned, though an output schema likely covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so schema coverage is complete. The description does not need to add parameter details, making the baseline score of 4 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'ROIs' in the context of the current MilliMap session. This distinguishes it from sibling tools like list_analysis_cards or get_cluster_markers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives or when not to use it. The description implies it is for listing ROIs but offers no contextual advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_clusteringA

Run MilliMap's clustering pipeline on the active dataset.

Runs PCA → neighbors (n_neighbors) → Leiden (resolution) → UMAP using Scanpy and updates the 3D view in MilliMap with the new cluster labels.

Args: resolution: Leiden resolution (higher = more clusters). Default 0.5. n_neighbors: k for the neighbors graph. Default 15.

ParametersJSON Schema

Name	Required	Description	Default
`resolution`	No
`n_neighbors`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the burden. It discloses that the tool updates the 3D view with new cluster labels, but does not mention whether previous clusters are overwritten, or any constraints like dataset size or computational cost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a clear intro sentence and a bulleted overview of steps and parameters. It avoids redundancy and front-loads the main purpose, though the argument list could be more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (which explains return values), the description adequately covers the tool's operation and side effects on the 3D view. Minor gaps in usage guidelines and parameter ranges are acceptable for a tool with two simple parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description partially compensates by explaining resolution as 'Leiden resolution (higher = more clusters)' and n_neighbors as 'k for the neighbors graph', along with defaults. However, ranges or impact details are missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs MilliMap's clustering pipeline on the active dataset, listing the exact steps (PCA, neighbors, Leiden, UMAP). It distinguishes itself from siblings that handle annotation, filtering, or marker finding.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for initial clustering, but lacks explicit guidance on when to use it versus alternatives like annotate_cluster or find_markers. No 'when not to use' or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_millimap_toolA

Escape hatch — run any of MilliMap's 30+ analysis tools by name.

Use when a workflow needs a tool not individually exposed above.

Examples of tool_name: run_deg_clusters, run_deg_roi, run_go_enrichment, find_spatially_variable_genes, run_neighborhood_enrichment, run_co_occurrence, run_centrality_scores, run_interaction_matrix, run_ripley, run_ligrec, run_pca, run_louvain, run_diffmap, run_draw_graph, run_paga, run_dpt, run_embedding_density, run_doublet_detection, normalize_data, find_highly_variable_genes, score_cell_cycle, create_dotplot, create_heatmap, create_stacked_violin, annotate_clusters.

Args: tool_name: Exact tool name from the list above. tool_args_json: JSON string of arguments, e.g. '{"group_a": "1", "group_b": "2"}'.

ParametersJSON Schema

Name	Required	Description	Default
`tool_name`	Yes
`tool_args_json`	No		{}

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as read-only/write, error handling, or side effects. It only lists tool names and gives an arg example, leaving the agent uninformed about runtime behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a clear header, usage line, and a list of examples. Every sentence adds value, and the structure is front-loaded with the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (30+ sub-tools) and the presence of an output schema, the description covers the essential purpose and usage. It could be improved by adding error handling notes or more details on tool_args_json format, but it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by listing valid tool_name examples and providing a JSON example for tool_args_json. However, it does not fully explain the expected structure of tool_args_json beyond the single example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is an 'Escape hatch' to run any of MilliMap's 30+ analysis tools by name, with a long list of examples. This distinctively separates it from sibling tools which are specific tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Use when a workflow needs a tool not individually exposed above,' providing explicit context for when to use. It lacks explicit alternatives but the sibling list naturally serves that purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

score_gene_signatureA

Score a gene signature across all cells and add it as an obs column.

Use this to apply a published signature (e.g. exhausted T cell markers, EMT genes) to the dataset. The score becomes a colorable field in MilliMap.

Args: genes: List of gene symbols to score together. score_name: Name for the new obs column (default 'mcp_score').

ParametersJSON Schema

Name	Required	Description	Default
`genes`	Yes
`score_name`	No		mcp_score

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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 explains that the score becomes a colorable field in MilliMap and describes the parameters. However, it does not disclose side effects, permissions, or the scoring algorithm.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences plus parameter details. It is front-loaded with the main action and efficiently explains the tool without unnecessary text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description need not detail return values. It adequately covers purpose, usage, and parameters. The scoring algorithm is not explained, but that is acceptable for a tool that adds a column.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 that 'genes' is a list of gene symbols and 'score_name' is the name for the new obs column with a default. This goes beyond the schema's type-only information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scores a gene signature across all cells and adds it as an obs column. It uses specific verbs and resources, and distinguishes from siblings like annotate_cluster and find_markers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear use case ('apply a published signature') and gives examples (exhausted T cell markers, EMT genes). It does not explicitly mention when not to use or alternatives, but the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_genesC

Case-insensitive search across marker genes. Returns matching genes and which cluster they mark.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It only mentions case-insensitivity and output structure, but does not disclose side effects, performance characteristics, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence) and front-loads the core purpose. However, it lacks any structural elements like bullet points or sections, which slightly reduces readability for complex scenarios.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, return values need not be detailed. However, the description does not explain limit behavior or result ordering, leaving a moderate gap for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides only minimal context for 'query' and 'limit' beyond their names. It does not explain acceptable formats or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs a case-insensitive search across marker genes and returns matching genes with cluster information. It is specific enough to differentiate from siblings like 'find_markers' but does not explicitly name any alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternative sibling tools. Missing explicit context about prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

12 tool updatesv0.1.0May 12, 2026
- First observedannotate_cluster
- First observedapply_qc_filter
- First observedfind_markers
- First observedgenes_for_cell_type
- First observedget_analysis_card
- First observedget_cluster_markers
- First observedlist_analysis_cards
- First observedlist_rois
- First observedrun_clustering
- First observedrun_millimap_tool
- First observedscore_gene_signature
- First observedsearch_genes

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation4/5

Most tools have distinct purposes, but the set of marker-related tools (find_markers, get_cluster_markers, genes_for_cell_type, search_genes) may cause some confusion as they all deal with marker genes, though descriptions clarify their specific roles.

Naming Consistency4/5

Tool names follow a verb_noun pattern in snake_case, which is consistent. However, 'genes_for_cell_type' deviates by starting with a noun instead of a verb, making it a minor inconsistency.

Tool Count5/5

With 12 tools covering clustering, annotation, marker retrieval, QC, and an escape hatch, the count is well-scoped for a single-cell analysis MCP server—each tool earns its place.

Completeness3/5

The tool surface covers core clustering and annotation but misses direct tools for data loading, normalization, or highly variable gene selection—essential preprocessing steps. The escape hatch partially fills these gaps but reliance on it for key operations indicates notable gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

pepita
dev.pepita.mcp
Read, edit, publish, and preview your pepita websites from Claude.
Content Management Systems Developer Tools
1
ShareWatch AOAuth
ai.sharewatch
Give Claude only the Google Drive files you choose. Every action logged.
Cloud Storage File Systems Workplace & Productivity
251
Fathom MCP ServerOAuth
io.github.agencyenterprise
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Communication App Automation Search
216
validatethat-mcp
io.github.RyanByrne
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Research & Data Product Management
2

Related MCP Servers

Tmux MCP Server
Shell Access Command Line
nickgnd
A
license
A
quality
F
maintenance
Enables Claude Desktop to interact with and view tmux session content, allowing AI assistants to read from, control, and observe terminal sessions.
Updated 7 months ago (2026-02-14 07:24 UTC)
13
256
299
MIT
BioNext-mcp
Bioinformatics Biology & Medicine
Cherine0205
A
license
A
quality
D
maintenance
Enables bioinformatics analysis through natural language conversations with Claude Desktop, automatically generating and executing Python scripts to produce HTML reports and visualizations.
Updated a year ago (2025-08-31 15:28 UTC)
3
23
9
MIT
screenmcp-claude-plugin
OS Automation Autonomous Agents
shimondoodkin
A
license
Not graded
quality
C
maintenance
Enables Claude to control the local desktop via screenshot, mouse, keyboard, and clipboard operations.
Updated 2 months ago (2026-06-28 17:13 UTC)
MIT
TradingView MCP Jackson
Finance Data Visualization
BluePandaNYC
F
license
Not graded
quality
B
maintenance
Enables Claude to control and read from the TradingView Desktop app, providing automated morning briefs, chart analysis, Pine Script development, and replay mode.
Updated 2 months ago (2026-07-10 22:52 UTC)
552
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/milliomics/millimap-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

millimap-mcp

How it works

Prerequisites

Install — into your existing MilliMap environment

If you set up MilliMap with conda (the recommended path)

If you set up MilliMap with pip (no conda)

Verify the install

Wire it up to Claude Desktop

Use an absolute path if millimap-mcp isn't on Claude Desktop's PATH

What Claude can see

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Use an absolute path if `millimap-mcp` isn't on Claude Desktop's PATH