Skip to main content
Glama
sbl-sdsc

MCP GeneLab Server

by sbl-sdsc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

set_output_directory

Idempotent

Set the session output directory before generating plots or CSV files so every downloadable result is saved to the user's chosen local path.

Instructions

Configure the output directory for files generated in THIS SESSION.

WHEN TO USE THIS TOOL: Call this tool at the START of a session (right after create_session), before any tool that produces a downloadable file (create_volcano_plot, create_venn_diagram, or any tool that emits a CSV). The path you specify is where the user wants finished files to end up on THEIR OWN local machine.

WHAT IT DOES: Stores the provided path string in the server's session-scoped state (keyed on your session_id — other sessions cannot see or change it). Every subsequent file-producing tool in this session uses this path:

  • As the user-facing save location shown in the response summary.

  • As the default target path in the save guidance emitted with every plot.

  • If the server is running locally (stdio transport), the server ALSO writes the file directly to this path.

IMPORTANT — DEPLOYMENT REALITY: When this MCP server is deployed remotely (ECS Fargate or any other container service), it runs in a container whose filesystem is NOT reachable from the user's machine. The server CANNOT write a file directly to the user's local disk over the network — no MCP server in a container can. The path you set here is a suggestion that propagates through the response in three ways, any of which lets the user save the file locally: (a) The plot is returned inline as ImageContent and renders in any MCP client that displays images (Claude Desktop, Cursor, Cline, Claude.ai web, ChatGPT, Gemini, etc.). The user can right-click and "Save Image As" — most clients default to the user's Downloads folder, which is usually what was asked for. (b) The path you set appears in the save guidance in the response. LLM clients with local filesystem access (Claude Code, Cursor, Cline, Claude Desktop with a filesystem MCP server) can write the file at exactly this path, re-fetching the canonical bytes via fetch_plot or the plot:// resource if needed. (c) Users without LLM-mediated filesystem access can save the inline image or the inline CSV text themselves.

VALIDATION: The path is stored as-is (the server does not verify it exists on the user's machine — it has no way to do so from inside a container). If you pass a relative path or an obviously malformed string the server will accept it; the failure will surface when the user tries to save the file locally.

Input Schema

NameRequiredDescriptionDefault
pathYesAbsolute path on the USER's local machine where output files (volcano plots, Venn diagrams, CSV exports) should be saved. Examples: '/Users/jane/Downloads', '/home/jane/Downloads', 'C:/Users/Jane/Downloads' (forward slashes work on Windows too with pathlib). Avoid trailing path separators.
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.7/5.0
Behavior5/5

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

Far exceeds the annotations (readOnlyHint=false, idempotentHint=true): it discloses session-scoped state keyed on session_id, that other sessions cannot read or change it, that the stored path propagates as summary and save-guidance, and critically that a remote container CANNOT write to the user's local disk and why. It also explains validation is a no-op. This is exactly the behavioral context 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.

Conciseness3/5

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

Header-based structure and front-loading are good, but it runs ~350 words for a single-parameter setter and contains repetition — the 'serves a suggestion / cannot write to local disk' point is restated across the IMPORTANT section, the (a)(b)(c) sub-list, and VALIDATION. Several sentences could be cut without losing meaning.

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 and only two parameters, the description covers everything an agent needs: when to call, what state is mutated, session keying, and the deployment caveats that shape what the agent should tell the user afterward. Nothing material 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: the path is stored as-is, the server cannot verify existence, and a relative or malformed path will still be accepted and only fail at save time. That validation-transparency is genuine added value over the schema text.

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 and resource ('Configure the output directory for files generated in THIS SESSION') with explicit session scoping. It clearly distinguishes itself from the read-only sibling get_output_directory and marks the session boundary. An agent knows exactly what this tool does without opening the 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?

A dedicated 'WHEN TO USE' section says to call it at the START of a session right after create_session and before any file-producing tool, naming the concrete siblings (create_volcano_plot, create_venn_diagram, CSV emitters). This is explicit when-to-use guidance with a concrete trigger point.

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