Skip to main content
Glama
sbl-sdsc

MCP GeneLab Server

by sbl-sdsc

fetch_plot

Read-onlyIdempotent

Retrieve the PNG bytes of a plot previously generated in this session. Use when the inline image is corrupted or you need the bytes for downstream steps.

Instructions

Re-fetch the PNG bytes of a plot previously generated IN THIS SESSION.

WHEN TO USE THIS TOOL: Call this when you need the canonical PNG bytes for a plot that's already been generated. Common cases:

  • The inline image in the original plot tool response was corrupted or didn't render in the client.

  • You need the bytes for a downstream step (e.g. embedding in a transcript, saving to a side file, base64-encoding for an external API).

  • The user asked to see the plot again without re-running the analysis.

WHAT THIS TOOL DOES NOT DO: It does NOT re-render the plot. It returns the same bytes that were registered when the plot was originally generated. If the underlying data has changed, re-run the plot tool itself (create_volcano_plot, create_venn_diagram); don't expect fetch_plot to pick up new data.

EQUIVALENT RESOURCE URI: This tool returns the same bytes that resources/read would return for plot://<session_id>/<filename>. Use whichever path your client supports better — resources for clients that render them well, this tool for clients that don't.

REGISTRY BOUNDS: Each session holds its last 8 plots (FIFO eviction). Older plots, and plots from other or expired sessions, return a clear "not in registry" error and need to be regenerated by re-running the source plot tool under the current session.

Input Schema

NameRequiredDescriptionDefault
filenameYesSuggested filename of a previously generated plot (e.g. 'venn_expression_2way_OSD-244.png'). Look at the most recent create_volcano_plot or create_venn_diagram response — the filename appears in the 'Save' block. Each session keeps its last 8 plots in memory.
session_idNoSession id returned by `create_session()`. This server serves many users from one process; the session id is what keeps your output directory and generated plots private to you. Pass the SAME value on every tool call. If the server replies that the session is unknown or expired, call `create_session()` again and use the new id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses registry bounds (last 8 plots, FIFO eviction), the error behavior for expired or foreign sessions, and equivalence to the resources/read URI. These are material operational facts the annotations cannot convey.

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?

Front-loaded with a single-sentence summary, then clearly labeled sections that make scanning fast. Slightly verbose in places (registry bounds restated in both description and schema), but every section carries actionable information.

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 no-output-schema lookup tool, the description covers return semantics (same bytes as resources/read), failure modes (not-in-registry, expired session), and the recovery path (re-run the source plot tool). Nothing needed to call it correctly is missing.

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 100%, so the schema already documents filename provenance and session_id semantics thoroughly. The description reinforces registry scope but adds little parameter-level meaning beyond what the schema states, so the baseline 3 applies.

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 operation (re-fetch PNG bytes) and resource (a plot previously generated in this session), and explicitly distinguishes itself from the sibling generators create_volcano_plot and create_venn_diagram by declaring it does NOT re-render. An agent can identify the tool's role without opening any schema.

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?

Provides an explicit 'WHEN TO USE' section with three concrete cases (corrupted inline image, downstream byte consumption, re-display without re-running analysis) and a 'WHAT THIS TOOL DOES NOT DO' section naming the alternatives to use when data has changed. When-to-use, when-not-to-use, and alternatives are all covered.

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