Galaxy MCP

Get a job's record, by its own id or by a dataset it created. The record carries the job's state, exit code, tool id and version, create and update times, params, inputs and outputs. It does not carry the job's stdout or stderr: a failed job's logs are one get_job_logs call away. Exactly one of dataset_id and job_id is required. Args: dataset_id: Galaxy dataset ID whose creating job to look up - a hexadecimal hash string (a 16-character hex string). Give this or job_id, not both history_id: Galaxy history ID containing the dataset - optional for performance optimizatio…

Read a job's logs: the stdout and stderr Galaxy keeps for it, each cut to a byte budget. One GET /api/jobs/{job_id}?full=true, answered with only the six log fields the full record adds -- tool_stdout, tool_stderr, job_stdout, job_stderr, stdout, stderr -- and nothing the plain get_job_details read already has. The four tool_* and job_* fields are null until the job has written them, and are then left out rather than returned empty; stdout and stderr are the older combined form of those pairs, which Galaxy always answers as a string, so a job that has not run reads as an empty stdout and stde…

Get a page and the content of its latest revision. Returns `content_editor`: the editable Galaxy-flavored markdown, with ENCODED ids in directives (e.g. `history_dataset_id=<encoded-dataset-id>`). This is the form to edit and pass back to update_page. Also returns `content_hash`, the hash Galaxy's page assistant uses over that source: read the page again and compare it to tell whether anyone changed the page since. Args: page_id: Encoded id of the page (from list_pages / create_page). include_rendered: When True, also return `content` -- the embed-expanded render form (inline…

Get the content of a single page revision. Edit `content_editor` and pass it to update_page; `content` is the same document with its embeds expanded for export, not the editable form. Galaxy only began sending content_editor on a revision after 26.1, so check `content_editor_source`: "content" means the server sent none and the editable text you are being handed is that expanded form -- editing it and saving it bakes the expansion into the page. Args: page_id: Encoded id of the page. revision_id: Encoded id of the revision (from list_page_revisions). Returns: GalaxyResult with t…

Get Galaxy server information including version, URL, and configuration details Also reports which tools this server is too old to run, in `unsupported_tools`, and whether its version could be read at all, in `version_known` -- an empty `unsupported_tools` means nothing is ruled out only when `version_known` is true. Returns: GalaxyResult with server information in data field

Get citation information for a specific tool Args: tool_id: ID of the tool Returns: GalaxyResult with tool citation information in data field. Each citation is Galaxy's {"format": "bibtex", "content": "<bibtex entry>"}, for the tool's default version.

Get detailed information about a specific tool including its input parameters. RECOMMENDED WORKFLOW: 1. First find tools using search_tools_by_name() or get_tool_panel() 2. Call this function with io_details=True to see all input parameters 3. Use the inputs schema to construct the inputs dict for run_tool() Args: tool_id: Galaxy tool identifier. Common formats: - Simple: "fastqc", "bwa", "upload1" - Toolshed: "toolshed.g2.bx.psu.edu/repos/devteam/fastqc/fastqc/0.73" io_details: Set True to include detailed input/output parameter schemas. Ess…

Return a ready-to-fill ``inputs`` skeleton for a tool, plus a compact schema. Call this before run_tool when you are unsure how to shape ``inputs``. Replace placeholders (e.g. ``<dataset_id>``) with real values. Repeats show one instance (``name_0|...``); duplicate with ``name_1|...`` to add more. The flattened-key convention is ``section|param``, ``cond|selector``, ``repeat_0|param``.

Browse the Galaxy tool panel (toolbox) one level at a time. The whole panel is megabytes on a production server, so it is never returned whole. Called with no arguments this lists the top-level entries - each section with the number of tools in it, plus any tools that sit outside a section. Pass section_id to list the tools in one section. Args: section_id: Panel section to open, from a previous summary call. Omit to list the sections themselves. limit: Maximum entries to return per page (default 100, max 500). A page is also cut short when it would not fit…

Return the exact XML test definitions (inputs, outputs, assertions, required files) for a Galaxy tool so an LLM can study real, working run configurations. Args: tool_id: ID of the tool to inspect tool_version: Optional version selector (use '*' for all versions) Returns: GalaxyResult with test cases in data field

Get current user information Returns: GalaxyResult with current user details in data field

Get one user-defined tool by its UUID, with its full representation. One request to Galaxy's single-tool endpoint, so a caller holding a UUID from list_user_tools() or create_user_tool() reads that tool's definition back without paging through the whole list. A value that is not a UUID is refused as not found before anything is sent. Args: uuid: The tool's UUID as list_user_tools() reports it (32 hex digits in 8-4-4-4-12 groups). The bare 32-digit, braced and urn:uuid: spellings name the same tool and are accepted too. Returns: GalaxyResult with the tool record (id, …

Get detailed information about a specific workflow Args: workflow_id: ID of the workflow to get details for - a hexadecimal hash string version: Specific version of the workflow (optional, uses latest if not specified) Returns: GalaxyResult with workflow information including steps, inputs, and parameters in data field

Return a ready-to-fill template plus a run guide for a workflow. Call this before invoke_workflow. Each slot lists its label, expected source (hda/hdca), accepted datatypes, collection type, and -- for parameters -- selectable `options` as [{label, value}]. On the `style=run` path these are Galaxy-resolved: reference-genome dbkeys come from the server regardless of history, and passing `history_id` additionally surfaces that history's compatible datasets as candidates. The legacy .ga fallback carries only the static restrictions baked into the workflow -- no server- or history-resolved values…

Import a workflow from IWC to the user's Galaxy instance Args: trs_id: TRS ID of the workflow in the IWC manifest Returns: GalaxyResult with imported workflow information in data field

Invoke (run) a workflow with specified inputs and parameters Args: workflow_id: ID of the workflow to invoke - a hexadecimal hash string inputs: Mapping of workflow inputs to datasets. Format: {'step_index': {'id': 'dataset_id', 'src': 'hda'}} where src can be: - 'hda' for HistoryDatasetAssociation - 'hdca' for HistoryDatasetCollectionAssociation - 'ldda' for LibraryDatasetDatasetAssociation - 'ld' for LibraryDataset params: Tool parameter overrides as a nested dictionary history_id: ID of history to store workflow outputs…

Get a simplified, paginated list of history IDs and names for easy reference Args: limit: Maximum histories to return per page (default 100, max 500). A page is also cut short when it would not fit the output budget. offset: Skip this many histories (default 0). Pass pagination.next_offset to walk to the following page. Returns: GalaxyResult with a list of {id, name} dictionaries in data, the page size in count, and the account's history total in pagination.total_items

List jobs, optionally narrowed to one history, one state and a time window. What an agent reconciling its own record of a history against Galaxy reads: the jobs updated since a time, in one history, newest first, a page at a time. Galaxy windows this index itself and reports no total, so the answer carries a count and no pagination block: a page shorter than limit is the last one, and the next page starts at offset + limit. Galaxy filters this index by history_id without looking the history up, so a well-formed id of a history that does not exist answers with an empty page -- the same answer…

List the revision history of a page. Each revision carries an `edit_source` ("user", "agent", or "restore") recording who made the edit. Args: page_id: Encoded id of the page. sort_desc: Newest-first when True (default oldest-first). Returns: GalaxyResult with the revisions (encoded id, page_id, edit_source, timestamps) in data and count. NEXT STEPS: - Read a revision: get_page_revision(page_id, revision_id) - Roll back: revert_page_revision(page_id, revision_id)

List Galaxy pages (markdown documents) viewable by the user. The history is what needs the newer server, and the whole tool is refused rather than only a filtered call: an older one has no history_id query parameter and no history_id on a page, so it would answer with every page the user can see and no way to tell a notebook from a report. A page attached to a history is a "Galaxy Notebook"; a standalone page is a "Report". Pass history_id to list only that history's notebooks. Args: history_id: Encoded history id. When set, returns only notebooks attached to that history. s…

List user-defined tools belonging to the current user, one page at a time. Args: active: If True (default), only show active tools. Set False to include deactivated tools. limit: Maximum tools to return per page (default 25, max 100). Each entry carries the tool's full representation, so a page is often cut short to fit the output budget; walk pagination.next_offset for the rest. offset: Skip this many tools (default 0). Pass pagination.next_offset to walk to the following page. Returns: GalaxyResult with this page of user tools (id, uuid, tool_id, nam…

List workflows available in the Galaxy instance, one page at a time Args: name: Filter workflows by name (optional) published: Include published workflows (default: False, shows only user workflows) limit: Maximum workflows to return per page (default 50, max 200). A page is also cut short when it would not fit the output budget. offset: Skip this many workflows (default 0). Pass pagination.next_offset to walk to the following page. Returns: GalaxyResult with this page of workflows in data, the page size in count, and the total matching the filt…

Resolve a verified quay.io/biocontainers image for a set of conda packages. Use this to pick the ``container`` for create_user_tool instead of guessing an image. The result is verified against quay.io rather than hallucinated, which avoids the most common user-defined-tool failure: inventing a tag, or using a bare image (e.g. "python:3.12-slim") that doesn't ship the libraries the tool imports. Args: packages: The conda packages the tool wraps, each as "name" or "name=version" (e.g. ["samtools=1.17", "bwa"]). Use canonical conda names you would `conda install` (e.g. "pand…

Semantic search for IWC workflows based on natural language description. Use this when you have a general analysis goal and want to find the best matching workflows. Uses BM25 ranking to search across names, descriptions, readmes, tags, and tool names. RECOMMENDED WORKFLOW: 1. Describe your analysis goal in natural language 2. Review ranked recommendations with match explanations 3. Get details for promising workflows: get_iwc_workflow_details(trs_id) 4. Import the best match: import_workflow_from_iwc(trs_id) Args: intent: Natural language description of your analysis goal. …

Roll a page back to an earlier revision. Creates a NEW revision from the target revision's content, recorded with edit_source="restore" (the history is append-only -- nothing is deleted). The new revision comes back the way get_page_revision returns one, with `content_editor` and the `content_editor_source` that says where it came from. Args: page_id: Encoded id of the page. revision_id: Encoded id of the revision to restore. Returns: GalaxyResult with the new restored revision's details in data.

Run a Galaxy tool on datasets in a history. RECOMMENDED WORKFLOW: 1. Create or select a history: create_history() or get_histories() 2. Upload data: upload_file() or upload_file_from_url() 3. Get tool parameters: get_tool_details(tool_id, io_details=True) 4. Call this function with properly formatted inputs 5. Monitor job: get_job_details() or check history contents Args: history_id: Galaxy history ID (a 16-character hex string). Get from create_history() or get_histories(). tool_id: Tool identifier. Common formats: - Simple built-in: "cat1", "Cut1", "upl…

Run a user-defined tool via the standard Galaxy tools API. Submits the UDT with POST /api/tools carrying the tool UUID. This synchronous endpoint runs user-defined tools on every Galaxy that supports them and needs no Celery -- unlike the newer POST /api/jobs tool-request path, which is Celery-only and 500s for UDTs on 26.0. It returns the job and output dataset handles immediately; the job then runs asynchronously on the cluster (poll it for state). Args: history_id: Galaxy history ID where outputs will be placed. tool_uuid: The UUID of the user-defined tool (from create_user_tool o…

Search for workflows in the IWC (Intergalactic Workflow Commission) manifest. IWC hosts curated, best-practice workflows for common bioinformatics analyses. This function searches across workflow names, descriptions, tags, and readmes. Results are paginated: pagination.total_items is how many workflows matched, pagination.next_offset is where the next page starts. RECOMMENDED WORKFLOW: 1. Search for workflows matching your analysis need 2. Review the results - check step_count for complexity, readme_summary for details 3. Call get_iwc_workflow_details(trs_id) for full information 4. Import w…

Recommend Galaxy tools based on a list of keywords. Matches on name and description first, then on accepted input formats, and keeps that order so paging is stable. Results are paginated: pagination.total_items is the full match count, pagination.next_offset is where the next page starts. Expensive: finding the format matches costs one detail lookup per tool that did not match by name, and every page repeats the whole scan. Prefer search_tools_by_name when a name or description substring will do. Args: keywords (list[str]): A list of keywords or phrases describing what you're looking fo…

Search Galaxy tools whose name, ID, or description contains the given query (substring match), followed by those whose name, ID and description hold every word of it between them. Results are paginated. pagination.total_items is how many tools matched in total; pagination.next_offset is where the next page starts (None on the last page). RECOMMENDED WORKFLOW: 1. Use this function to find tools by name/keyword 2. Review the returned tool IDs and names 3. Call get_tool_details(tool_id) for full input parameters 4. Call run_tool() with the correct inputs Args: query: Search query - matches…

Update an existing Galaxy history's metadata. Any combination of name, annotation, tags, deleted, and published can be updated in a single call. Fields left as None are not modified. Args: history_id: The ID of the history to update. Obtain this from get_histories() or list_history_ids(). name: New name for the history (optional). annotation: New annotation/description text for the history (optional). tags: New list of tags for the history (optional). Replaces any existing tags. deleted: If True, soft-delete the history; if False, restore a deleted history…

Update a page, creating a new revision when content changes. Replace one section instead of the whole page by passing section_heading (the exact heading line, e.g. '## Methods') with section_content (its new text, heading line included); a heading the page lacks is appended, and every section with that heading line is replaced, as Galaxy's page editor does. Markdown pages only. Pass the content_hash get_page returned as expect_hash and the write is refused if the page changed since you read it. That check is a read followed by the write, not one atomic request: it catches a page that moved be…

Upload a local file to Galaxy for analysis. Galaxy automatically detects the file type (FASTQ, BAM, BED, etc.) and indexes the file appropriately. Large files are uploaded efficiently. RECOMMENDED WORKFLOW: 1. Create a history: create_history("My Analysis") 2. Upload your data files with this function 3. Wait for upload to complete (check dataset state) 4. Run tools on the uploaded data: run_tool() Args: path: Local file path to upload. Supports common bioinformatics formats: - Sequences: .fastq, .fasta, .fa, .fq, .fastq.gz - Alignments: .bam, .sam, .cram -…

Upload a file from a URL to Galaxy Args: url: URL of the file to upload (e.g., 'https://example.com/data.fasta') history_id: Galaxy history ID where to upload the file - optional, uses current history (a 16-character hex string) file_type: Galaxy file format name (default: 'auto' for auto-detection) Common types: 'fasta', 'fastq', 'bam', 'vcf', 'bed', 'tabular', etc. dbkey: Database key/genome build (default: '?', e.g., 'hg38', 'mm10', 'dm6') file_name: Optional name for the uploaded file in Galaxy (inferred from URL if not provided) Returns: …