Skip to main content
Glama
ZengZichao

SwissBioPics MCP Server

by ZengZichao

get_cell_svg

Retrieve raw SVG image content for a cell type by ID, name, or filename, including interactive illustration and embedded subcellular location data.

Instructions

Retrieve the raw SVG image content of a cell type.

The SVG contains the full interactive cell illustration with embedded subcellular location data (SL IDs, names, and descriptions as hidden text elements).

Args: cell_identifier: Either a numeric cell ID (e.g. 8719) or a cell-type name (e.g. Animal_cell). You can also pass the SVG file name directly (e.g. Animal_cells.svg).

Returns: The raw SVG XML content as a string (may be large).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cell_identifierYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It adds genuine behavioral value by disclosing that the SVG embeds subcellular location data as hidden text elements and that the result may be large. However, it says nothing about error behavior for unknown identifiers, caching, or how the SVG relates to the other location tools.

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 prose is front-loaded with the purpose, then the embedded-data note, then args and returns. The docstring-style Args/Returns scaffolding is slightly redundant given an output schema exists, but it is compact and every line carries information.

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?

An output schema exists, so the Returns line is unnecessary but harmless. Given a one-parameter tool, the description covers input formats, output nature, and embedded content adequately; only sibling relationships and failure modes are absent.

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% for the single parameter, so the description must compensate, and it does: it enumerates all three accepted forms (numeric ID, cell-type name, or SVG file name) with examples. Usage examples for the name formats are the only thing missing.

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 gives a specific verb and resource: 'Retrieve the raw SVG image content of a cell type.' An agent can distinguish this from get_cell_type_detail (likely text metadata) by the word 'SVG', but the description never explicitly contrasts itself with those siblings, keeping it just short of a 5.

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?

There is no statement of when to use this tool versus get_cell_type_detail or get_swissbiopics_info, nor any prerequisites. The accepted identifier formats hint at inputs but provide no selection guidance.

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