F
licenseNot graded
qualityD
maintenanceEnables LLMs to interact with Hopsworks for platform management, feature store operations, model lifecycle, jobs, and integrations.
-
cellpy-mcp
Officialby cellpy
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., "@cellpy-mcpLoad my cell file and plot capacity vs cycle."
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.
cellpy-mcp
An MCP server for cellpy. It lets an agent — or a chat window — load battery cells, collect them into frames, render figures, export data, look up how any cellpy call works, and set up a batch project. Without writing any Python.
pip install cellpy-mcp
cellpy mcp install # register it with your chat clientThen restart the client and ask it to plot something.
Who it is for
People building on cellpy — a GUI, a script that automates cell handling. The tools are the useful API, and
describe_apigives real signatures from the version you have installed.People who just want to ask. Open a chat window, point it at a file, ask for capacity versus cycle. The prompts below are pickable starting points, so you do not have to know what to ask for.
People who would rather not use a terminal.
new_projectiscellpy newwithout the command line.
Nothing is hosted. Under stdio your chat client starts the server itself, on your machine, reading your files — there is no service to sign up for and nothing leaves the machine except what you paste into the chat.
Related MCP server: data-analysis-mcp
What it can do
Cells and figures:
Tool | What it gives you |
| loaders, and whether each can actually run on this machine |
| a handle, cycle count, mass, summary column names |
| what is loaded |
| the 20 summary families, marked available or missing-columns |
| a handle, row count, columns, |
| a few rows, capped at 20 |
| writes a figure; returns trace types and points plotted |
| writes csv/parquet/json; returns rows and bytes |
The cellpy API — "how does this call work, and what are its arguments":
Tool | What it gives you |
| calls matching a name or a docstring line |
| signature, argument types and defaults, docstring, |
Batch templating:
Tool | What it gives you |
| registered and local templates, and which is the default |
| a project from a template; returns the notebooks it made |
Prompts: analyse_cell, start_batch_project, explain_call.
Where it may read and write
Everything is confined to a set of roots, and both reads and writes are checked — an unchecked write would make the read check decoration.
By default the roots are the directories cellpy already knows about
(rawdatadir, cellpydatadir, outdatadir, notebookdir), because you told
cellpy where your data is when you set it up. Override with CELLPY_MCP_ROOT,
which takes several directories separated the way PATH separates them:
CELLPY_MCP_ROOT=/data/cells:/data/out cellpy mcp serveRoots that are not plain local directories are dropped: rawdatadir is often
scp://host/…, and containment here is pathlib-based and cannot express
"inside that remote share". If cellpy has no configured paths at all, the
single root is ~/cellpy_mcp — never your whole filesystem.
Four things it does on purpose
Handles, not data. Only preview_collection returns rows. A tool result
goes into a model's context window, and one collected summary is ~29 kB of CSV
while a raw figure can be several MB.
Results carry the traps. render returns trace_types alongside
points_plotted and rows_collected, so an agent that asked for a density film
can see it got histogram2d rather than lines, and one that forgot
direction="both" can see it plotted 891 of 2328 rows. describe_api returns
undocumented_parameters for the same reason: cellpy documents about half its
arguments, and a model should know when the package never said.
It follows the docstring's own cross-references. CellpyCell.get_cap takes
23 arguments, documents none, and points at
cellpy.readers.capacity_curves.get_cap — which documents 22 of 24. Following
that takes argument coverage across the documented API from 51% to 72%. Only a
docs site resolves those markers; nobody reading a docstring does.
One client per process. State is process-wide, deliberately: the MCP SDK does not give a tool a stable session identity, and under stdio each client spawns its own process anyway. Do not put this behind a shared HTTP endpoint as written.
Limits worth knowing
load_cellblocks, with no progress and no cancellation, so a slow load can look like a hang to a client. This is the gap most worth closing.No quota and no eviction: an agent can fill the sandbox with figures, and cells stay in memory until the process exits.
new_projecthas to create the project directory itself, becausecellpy newprompts even withno_input=True(cellpy#990). It also downloads a cookiecutter from GitHub on first use.
Running it without cellpy's shim
cellpy mcp arrived in cellpy 2.1.3.post3, which this package requires. The
same things are reachable without it:
python -m cellpy_mcp serve
python -m cellpy_mcp install --dry-run
python -m cellpy_mcp statusBackground
The design, the measurements behind it, and a two-round prototype log are in cellpy#840.
MIT licensed.
Available Tools
12 toolscollectA
Build a collection. kind is one of: summary, cycles, ica, dva.
Returns a handle and the frame's shape — never the frame. Use preview_collection for rows, export_collection for the numbers.
For summary, give either columns or family (a name from
describe_plot_families; the family supplies its own collect options).
For cycles / ica / dva, give cycles.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| cells | No | ||
| cycles | No | ||
| family | No | ||
| columns | No | ||
| group_it | No | ||
| max_cycle | No |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It usefully states the return contract: 'Returns a handle and the frame's shape — never the frame,' and notes that family supplies its own collect options. However, it does not disclose side effects, permissions, handle lifecycle, or whether repeated calls create persistent resources, leaving some behavioral ambiguity.
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 short paragraphs, each earning its place: definition, return behavior plus alternatives, and per-kind parameter rules. It is front-loaded with the core purpose and avoids redundant or filler language.
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?
The description gives key return/routing guidance and covers the main usage patterns for each kind. However, with no annotations, no output schema, and zero schema parameter descriptions, omitting cells, group_it, max_cycle, and the exact handle/shape format leaves notable gaps for full autonomous invocation.
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?
The input schema has no parameter descriptions (0% coverage), and the description compensates meaningfully for kind, columns, family, and cycles, including the summary-vs-cycles rule. But cells, group_it, and max_cycle are mentioned nowhere, leaving three of seven parameters semantically undocumented.
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 states a specific verb and resource: 'Build a collection' with kind variants summary, cycles, ica, dva. It clearly distinguishes itself from siblings by explaining that it returns a handle and shape, never the frame, and by naming preview_collection and export_collection as the tools for rows and numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool: when you need a collection handle, not rows (preview_collection) or numbers (export_collection). It also gives per-kind parameter guidance, telling the agent to use columns/family for summary and cycles for cycles/ica/dva, so the decision is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_apiA
What a cellpy call takes and what it does, from the installed package.
name is a dotted path (cellpy.get, cellpy.collect.collect_summary)
or a bare name (get_cap) looked up in the index.
Read undocumented_parameters before answering a question about one of
them. cellpy documents roughly half its arguments, so an argument
missing from doc means the package never said what it does — not that
it does not matter. Ask again with include_source=True rather than
guessing.
When delegates_to is set, the docstring pointed at another call with a
Sphinx reference and delegate_doc is where the arguments are actually
described — read it, it is usually the real documentation.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| include_source | No |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses meaningful behavioral details: name resolution via dotted path or bare name, the meaning of missing doc entries, the role of undocumented_parameters, and the delegates_to/delegate_doc indirection. This goes far beyond what the input schema reveals.
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 front-loaded with a clear purpose sentence, then uses short, scannable paragraphs for name resolution and edge cases. Every sentence contributes actionable information; there is no filler or repetition.
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?
For a 2-parameter tool with no output schema and no annotations, the description is remarkably complete. It covers the main name semantics, the undocumented-argument pitfall, and the delegate-doc indirection. It could still explicitly describe the return shape or error behavior, but the most decision-relevant context is present.
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 description coverage is 0%, so the description must compensate. It clearly explains name as a dotted path or bare name looked up in the index, and it gives practical meaning to include_source by framing it as the way to get source when documentation is missing. It does not exhaustively define include_source's output, but it adds real value beyond the 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 opening sentence is a precise verb+resource statement: it describes what a cellpy call takes and what it does, scoped to the installed package. This makes the tool's purpose immediately distinct from siblings like list_instruments, load_cell, and describe_plot_families.
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 gives strong procedural guidance: read undocumented_parameters before answering, use include_source=True rather than guessing, and read delegate_doc when delegates_to is set. However, it never explicitly says when to prefer this tool over alternatives like search_api, so alternative-selection guidance is left implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_plot_familiesA
Summary plot families cellpy offers, and whether the loaded cells support them.
Availability is judged on what a family asks the summary for
(summary_options().columns), not on the columns it draws — the drawn
list includes columns the collector manufactures, and checking those
reports "missing columns" for families that work perfectly well.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/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 behavioral-disclosure burden. It discloses a non-obvious and important behavior: availability is judged by what a family asks the summary for, not by the columns it draws, and warns that checking drawn columns produces false 'missing columns'. This is substantive context beyond the basic function.
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 with the main purpose front-loaded and a valuable caveat in the second sentence. Every sentence earns its place, with no redundant wording.
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?
For a zero-parameter descriptive tool with no output schema, the description gives the core purpose and the key correctness caveat. It does not specify the exact return format or prerequisites, but the most important contextual nuance is present.
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 tool has zero parameters and an empty input schema, so parameter semantics are trivially complete. The baseline of 4 for zero-parameter tools applies; no parameter explanations are needed.
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 what the tool does: summarize the plot families cellpy offers and report whether loaded cells support them. This specific resource—plot families plus cell support—distinguishes it from siblings like describe_api and list_cells.
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 used after cells have been loaded and references summary_options().columns, but it does not explicitly state when to prefer this tool over describe_api or other alternatives. Usage context is present but mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_collectionB
Write the collected frame to path (.csv, .parquet or .json).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| handle | Yes |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the tool writes a frame to a file and lists supported formats, but it does not disclose overwrite behavior, path handling, or whether the operation is reversible. This is adequate but not fully 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 a single focused sentence with no redundant words. The core action and file format constraints are front-loaded, making it easy for an agent to parse quickly.
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?
For a two-parameter tool, this is minimally viable: the action, target, and formats are stated. But with no annotations and no output schema, the description omits guidance on when to use the tool, what 'handle' must refer to, and what happens after a successful write.
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%, so the description must compensate. It adds meaningful semantics to 'path' by specifying supported file extensions and implies that 'handle' identifies the collected frame. However, 'handle' is never explicitly explained, leaving a notable gap for a required parameter.
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 uses a specific verb ('Write') with a clear resource ('the collected frame') and target ('path'), and notes the supported file formats. It distinguishes export_collection from collection-building tools like collect and preview_collection, though it does not explicitly name siblings.
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 is given on when to use this tool versus alternatives such as preview_collection or collect. The phrase 'collected frame' implies it should be used after collection, but this is left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_cellsA
The cells loaded in this session.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavior. It adds the useful constraint that only session-loaded cells are returned, which helps set expectations. However, it doesn't explicitly state that the operation is read-only, nor does it describe return format or behavior when no cells are loaded.
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 short sentence that immediately states what is listed and the scope, with no filler. This is appropriately concise for a zero-parameter listing tool.
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 there are no parameters and no output schema, the description is mostly sufficient: an agent knows the tool lists the current session's loaded cells. It would be slightly stronger if it indicated the returned form of a cell, but for a simple list call the gap is minor.
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 tool takes zero parameters, so the schema is already complete; the baseline of 4 applies. The description does not need to explain parameters and introduces no ambiguity.
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 phrase 'The cells loaded in this session' identifies the resource (cells) and the scope (session-loaded), aligning with the verb implied by the tool name. It is distinguishable from load_cell, which is about loading rather than listing. However, it lacks an explicit verb or comparison to siblings.
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 is provided about when to use list_cells versus siblings such as load_cell or list_instruments, and there are no exclusions or prerequisites. The 'in this session' qualifier hints at context, but the description never states when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_instrumentsA
Which cellpy loaders exist, and which can actually run on this machine.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It conveys a read-only probing behavior—checking existence and local runnability—but does not disclose how runnability is determined or what the output format looks like.
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, compact sentence that front-loads the tool's purpose and wastes no words. It efficiently conveys both existence checking and runnability checking.
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?
For a zero-parameter tool with no output schema, this description is sufficiently complete for selection and invocation. It tells the agent what information the tool provides, though it does not specify the exact output shape.
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 tool has zero parameters and the schema coverage is complete, so no parameter explanation is needed. The baseline for zero-parameter tools is 4, and nothing is 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 what the tool does: it identifies which cellpy loaders exist and which are runnable on the current machine. This distinguishes it from siblings like load_cell and list_cells, which operate on data rather than discovering loader capabilities.
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 this tool is for environment/capability discovery, and the sibling context reinforces that it is not for loading or listing data. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesA
Batch templates available for new_project, registered and local.
cellpy new --list prints this and returns nothing, so this reads the
registry directly (jepegit/cellpy#991 asks for a library form).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden. It discloses a key behavioral trait: it reads the registry directly instead of relying on the CLI output, indicating a read-only operation. It does not discuss error cases or environment prerequisites, but for a zero-parameter list tool, this is acceptable but not rich.
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, with the primary purpose front-loaded. The second sentence explains the workaround and references a GitHub issue, which is slightly tangential for an agent but not wasteful. Overall compact and clear.
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?
For a tool with zero parameters and no output schema, the description covers what it lists and why it exists. It implies the return is the list of templates but does not explicitly state the return type or format. Given the simplicity and sibling context, the gap is minor.
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 tool has no parameters and schema coverage is 100% by default. The description adds relevant context about the CLI limitation and the registry read, which is more than enough for a parameterless tool. Baseline 4 applies.
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 a specific verb and resource: 'Batch templates available for new_project, registered and local.' It identifies what the tool lists and for which project type, and the resource type (templates) distinguishes it from sibling list tools. However, it does not explicitly name alternatives or contrast with them.
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 provides context by noting that the CLI command 'cellpy new --list' prints the templates and returns nothing, so this tool reads the registry directly. This implies usage when programmatic access to the template list is needed. It does not explicitly state when not to use it or how to choose among sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_cellA
Load one cell file and return a handle plus what the data can support.
mass_mg is the active-material mass. Without it every *_gravimetric
column is computed against a default of 1.0 mg — the numbers still
appear, they are simply wrong, so supply it when you know it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| mass_mg | No | ||
| instrument | No |
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 behavioral burden, and it does meaningful work: it warns that omitting mass_mg silently defaults gravimetric columns to 1.0 mg, producing numbers that 'appear' but are 'simply wrong.' It also discloses the return shape at a high level. Side effects and error behavior are not covered, but the default-value behavior is a significant transparency win.
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 short paragraphs with the purpose front-loaded and no filler. The mass_mg warning earns its place because it prevents a likely silent misinterpretation.
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 no output schema and no parameter descriptions, the description provides a clear purpose, a high-level return description, and the critical mass_mg gotcha. However, it omits instrument semantics and does not explicitly position the tool relative to siblings, leaving some gaps for an agent deciding whether and how to call it.
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%, so the description must compensate. It gives strong semantic and consequence-level meaning for mass_mg, but path and instrument are left with no explanation beyond their names and types.
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?
States a specific action ('Load one cell file'), names the resource, and says it returns a handle plus what the data can support. This is distinct from sibling tools like list_cells and collect, which operate at a different scope.
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?
There is no explicit when-to-use or when-not-to-use guidance and no named alternatives. The intended use is implied by 'Load one cell file,' and the mass_mg paragraph is parameter advice rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
new_projectA
Create a batch project from a template — the cellpy new workflow.
project is the folder, experiment the lookup value; the template
dates the experiment folder itself, so experiment="exp001" becomes
something like 2026_09_05_exp001. Writes inside the data directories
only.
Downloads the cookiecutter from GitHub on first use.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| template | No | ||
| directory | No | ||
| experiment | Yes |
TDQS
A3.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it does so well. It states the filesystem scope ('Writes inside the data directories only'), the side effect ('Downloads the cookiecutter from GitHub on first use'), and the naming behavior with a concrete example. This gives an agent meaningful expectations beyond the schema.
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 tight and front-loaded. Each sentence earns its place: the first states the purpose, the second clarifies the key parameters with an example, and the third discloses the important download side effect. There is no filler.
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?
The description is strong on required parameters and behavioral side effects, but it leaves gaps: no return/output details, no explanation of the `template` and `directory` parameters, and no definition of what 'data directories' concretely means. Since there are no annotations and no output schema to compensate, these gaps matter for correct invocation.
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?
The description meaningfully explains the two required parameters: `project` is the folder, `experiment` is the lookup value, and it shows how the experiment name gets date-prefixed. However, the optional `template` and `directory` parameters are not described at all, and schema description coverage is 0%, so the description only partially compensates for the missing parameter documentation.
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 opens with a specific verb and object: 'Create a batch project from a template', and anchors it to the `cellpy new` workflow. It also clarifies the roles of `project` and `experiment`, which helps distinguish this tool from sibling tools like `list_templates` or `collect`.
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 when-to-use or when-not-to-use guidance is provided. There is no mention of alternatives, prerequisites, or conditions that would make a sibling tool more appropriate. The usage context is only implied by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preview_collectionB
A few rows, capped. This is the only tool that returns data, on purpose.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | ||
| handle | Yes |
TDQS
B3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does communicate a meaningful trait: returned data is capped to a few rows. However, it does not disclose whether the operation is read-only, whether there are side effects, or how the cap is determined beyond a vague 'few.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is refreshingly short and avoids filler, with the cap behavior and the 'only tool' distinction both carrying meaning. However, the first sentence is a fragment and the overall message is cryptic rather than clearly structured, so it reads more like a teaser than a polished tool description.
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?
Given that the tool has a required 'handle' parameter, no annotations, and no output schema, the description is incomplete. It does not explain what 'handle' refers to, what the returned rows contain, or how the cap interacts with the 'rows' parameter. An agent could invoke it, but would have to guess essential invocation details.
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 only loosely references 'rows' with 'A few rows, capped.' The required 'handle' parameter is completely unexplained, leaving the agent to guess what identifier is needed. The description does not compensate for the total lack of schema parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description hints that the tool returns a capped set of rows and claims to be the only tool that returns data on purpose, which signals a preview-like function. However, it never explicitly states the verb and resource (e.g., 'preview a collection') and the core purpose must be inferred from the tool name and the terse phrase.
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 'This is the only tool that returns data, on purpose,' giving the agent a clear selection criterion among sibling tools. It does not name alternatives or elaborate on when not to use it, but the 'only tool' statement is a strong, clear usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
renderB
Draw a collection and write the figure to path (.json or .html).
kind="film" gives a 2-D density rendering. Note it is a kind, not
a layout: on cellpy 2.1.2 layout="film" silently drew lines instead
(fixed in 2.1.3). The returned trace_types is how you check what you
actually got.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| path | Yes | ||
| handle | Yes | ||
| layout | No | per_cell | |
| spread | No | ||
| direction | No |
TDQS
B3.2/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 and does well by documenting a concrete version-specific bug (cellpy 2.1.2 layout='film' drew lines) and providing a verification strategy via returned trace_types. It also makes the file-writing side effect explicit, though it doesn't mention overwriting 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 compact, front-loaded, and every sentence earns its place. The main action is stated immediately, and the version warning is dense but necessary context.
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?
Given six parameters, no output schema, and no annotations, the description is too sparse for a full invocation. The agent knows the output path and the film gotcha, but lacks clear semantics for handle, spread, direction, and most layout values.
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%, so the description must compensate. It explains path formats and clarifies kind versus layout for 'film', but the required handle parameter is never described, and spread/direction/layout general semantics are left undocumented.
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 a specific action ('Draw a collection') and output ('write the figure to path'), with file formats (.json/.html). It is not a tautology and gives readers a solid sense of what render does, though it doesn't explicitly differentiate it from siblings like preview_collection or export_collection.
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?
The description does not say when to choose render over the sibling tools such as preview_collection or export_collection. It contains a useful note about kind='film' versus layout='film', but that is parameter-level guidance, not tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_apiA
Find cellpy calls by name, or by what their first docstring line says.
Use this when you know the task but not the call — "average cycles",
"loading", "mass". describe_api then gives the arguments.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosure. It does reveal that matching happens against call names and first docstring lines, but it does not mention output format, limit behavior, or how results are ordered.
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?
Three short sentences, each earning its place. The core behavior and usage guidance are front-loaded with no redundant filler.
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?
For a simple two-parameter search tool with no output schema, the description covers search scope, when to use it, and the natural next step. Adding explicit return-format details would improve it, but the low complexity means the essential calling guidance is present.
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 schema description coverage at 0%, the description is the main source of meaning for parameters. It clearly defines what query means, but it does not explicitly explain the limit parameter or the exact matching semantics.
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 opens with a specific verb and resource: 'Find cellpy calls by name, or by what their first docstring line says.' It clearly distinguishes search_api from describe_api by positioning the latter as the follow-up step for retrieving arguments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this when you know the task but not the call' gives an explicit trigger condition, and the examples plus the 'describe_api then gives the arguments' handoff tell the agent exactly when and how to use it.
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 updates
v0.1.0- First observed
collect - First observed
describe_api - First observed
describe_plot_families - First observed
export_collection - First observed
list_cells - First observed
list_instruments - First observed
list_templates - First observed
load_cell - First observed
new_project - First observed
preview_collection - First observed
render - First observed
search_api
TDQS
A3.9/5.0
Disambiguation5/5
Each tool targets a distinct resource or action: listing loaders, cells, and templates; loading; collecting; previewing; exporting; rendering; and API lookup. The list_* and describe_* tools are differentiated by their object type, and the collect/preview/export trio is clearly separated by what it returns or writes.
Naming Consistency4/5
Most tools follow a clear verb_noun snake_case pattern (list_cells, load_cell, export_collection, search_api). Minor deviations like 'collect', 'render', and 'new_project' are still readable and predictable, so consistency is high but not perfect.
Tool Count5/5
Twelve tools is well-scoped for a domain-specific analysis server. Each tool covers a meaningful part of the cellpy workflow without redundancy or bloat.
Completeness5/5
The set covers the full workflow: inspecting environment support, loading cells, building collections, previewing and exporting data, rendering figures, discovering API calls, and creating batch projects. The self-documentation tools fill gaps that would otherwise require external knowledge of cellpy.
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- OleanderOAuthdev.oleander
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Read a project's prompts, logs and agents, and send new work to the agent on your own machines.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables data analysis and visualization operations such as loading CSV/Excel/JSON files, computing summary statistics, generating charts, and exploring datasets via SSE/HTTP.MIT
- AlicenseNot gradedqualityCmaintenanceEnables LLM clients to run Python code in a persistent, user-selected interpreter via MCP, with tools for data loading, summaries, regressions, diagnostics, and plotting, while keeping sessions alive between calls and isolating crashes.MIT
- AlicenseNot gradedqualityCmaintenanceProvides a comprehensive MCP server for data preprocessing, analysis, mathematical modeling, and visualization, enabling agents to load, clean, analyze, model, and plot data with tracking and dynamic method extension capabilities.Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/cellpy/cellpy-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server