Skip to main content
Glama
sbl-sdsc

MCP GeneLab Server

by sbl-sdsc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_save_script

Read-onlyIdempotent

Retrieve save instructions for a plot generated in the current session, offering right-click, filesystem, or MCP resource methods to save it locally.

Instructions

Return guidance for saving a plot generated in THIS SESSION to the user's local filesystem.

WHEN TO USE THIS TOOL: Call this only when the user explicitly asks for save guidance for a specific plot — for example, "how do I save the volcano plot to my Downloads folder?" or "I can't right-click — give me another way to save the plot." By default plot tools (create_volcano_plot, create_venn_diagram) return only a SHORT save hint to keep response sizes manageable. The detailed save options are delivered on demand via this tool, so they don't burn conversation context unless the user actually wants them.

HOW IT WORKS: Each plot tool registers the PNG bytes of the plot it generated in the calling session's registry (up to the last 8 plots; older entries are evicted FIFO). Calling this tool with the plot's suggested filename returns a markdown block with three save options:

  • Option A (right-click save on the inline image)

  • Option B (ask your LLM client to save via filesystem access, optionally re-fetching the canonical bytes through fetch_plot or the plot:// resource if the inline image was corrupted)

  • Option C (fetch the canonical PNG bytes via resources/read on the plot://<session_id>/ URI for clients that support MCP resources)

The response itself contains no PNG bytes — only references to the plot:// resource URI and the fetch_plot tool, both of which deliver the bytes through a separate request.

LISTING AVAILABLE PLOTS: Call this tool with no filename argument to list the filenames of all plots currently held in this session's registry. Useful when the user asks for save guidance but doesn't remember which plot they want.

Input Schema

NameRequiredDescriptionDefault
filenameNoSuggested filename of a recently generated plot (e.g. 'volcano_plot_OSD-244_expression_30_days_vs_60_days.png'). Look at the most recent create_volcano_plot or create_venn_diagram response — the filename appears in the 'Save' block. Omit this parameter to list the filenames of all plots currently available in this session's registry.
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.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), but the description adds substantial behavioral context beyond them: a session registry capped at the last 8 plots with FIFO eviction, the fact that the response contains no PNG bytes, and the three concrete save options offered. This is exactly the kind of operational detail annotations cannot express.

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 the core purpose and then cleanly partitioned into WHEN TO USE, HOW IT WORKS, and LISTING AVAILABLE PLOTS sections. It is on the long side, but nearly every sentence carries distinct load-bearing information (eviction cap, no-bytes caveat, option breakdown), so little is wasted.

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?

With no output schema, the description carries the return-value burden itself: it describes the markdown block, the three save options, and explicitly states the response contains no PNG bytes and points to plot:// URIs instead. Nothing needed to invoke or interpret the tool correctly is missing.

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 100%, so baseline is 3. The description reinforces parameter behavior with a dedicated 'LISTING AVAILABLE PLOTS' section explaining that omitting filename lists all plots, tied to a real use case ('user doesn't remember which plot'), adding mild meaning over 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?

States a specific verb+resource with scope: 'Return guidance for saving a plot generated in THIS SESSION to the user's local filesystem.' It also names the sibling plot tools (create_volcano_plot, create_venn_diagram) and the fetch_plot/plot:// alternatives, so an agent can distinguish it 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?

Has an explicit 'WHEN TO USE THIS TOOL' section with the trigger condition ('only when the user explicitly asks for save guidance'), concrete user-phrasing examples, and the rationale that plot tools return only a short hint by default. It also routes to alternatives (fetch_plot, plot:// resource) for re-fetching bytes.

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

Deploy Server

Other Tools