Skip to main content
Glama

Analyse a whole slide

analyze_slide
Idempotent

Analyzes whole-slide images in the background, sampling or covering tissue tiles to measure nuclei density, size, and variation, with optional cell typing; fetch results later.

Instructions

Analyse a whole-slide image in the background and wait up to wait_seconds for the result.

coverage "sample" (default) analyses up to max_tiles tiles spread over the tissue in a few minutes. "full" analyses every tissue tile (up to 3,000, about 200 mm2) in parallel parts and tints the overview as a density heatmap: a few minutes for a biopsy, longer for big resections. Cell types are on by default for a sample and off for full coverage (they take about 15x longer per tile); set cell_types to change that.

Finds the tissue, samples up to max_tiles tiles of it (256 x 256 um each at 40x) and runs the quality check and StarDist nuclei on each: nuclei per mm2, nuclear size in um2, size variation and enlarged nuclei across the slide, plus per-tile values. With cell_types (default) each nucleus is also typed as tumour, immune, connective tissue, dead or normal epithelial (HoVer-Net, PanNuke weights: research and education only), about 40 seconds a tile, so max_tiles defaults to 12 (16 without cell types). Allow a minute more when the models start. If it's still running when the wait ends, call get_slide_analysis later. An analysis already running is waited for; restart=true starts a new one (e.g. with more tiles).

Input Schema

NameRequiredDescriptionDefault
restartNoStart a new analysis even if one already exists for this slide.
coverageNo'sample': up to max_tiles tiles spread over the tissue, in minutes; 'full': every tissue tile in parallel, with a density heatmap.sample
image_idYesId of a whole slide: the imageId (a UUID string) returned by upload_slide or upload_slide_from_url.
max_tilesNoTiles to analyse for a sample (default 12 with cell types, 16 without).
cell_typesNoAlso type each nucleus (tumour, immune, connective tissue, dead, normal epithelial); default on for a sample, off for full coverage.
wait_secondsNoHow long to wait for the result; if it isn't ready, get_slide_analysis reads it later.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.8.1
    • addedInput schema / properties / cell_types / description
      Added value: +"Also type each nucleus (tumour, immune, connective tissue, dead, normal epithelial); default on for a sample, off for full coverage."
    • addedInput schema / properties / coverage / description
      Added value: +"'sample': up to max_tiles tiles spread over the tissue, in minutes; 'full': every tissue tile in parallel, with a density heatmap."
    • addedInput schema / properties / image_id / description
      Added value: +"Id of a whole slide: the imageId (a UUID string) returned by upload_slide or upload_slide_from_url."
    • addedInput schema / properties / max_tiles / description
      Added value: +"Tiles to analyse for a sample (default 12 with cell types, 16 without)."
    • addedInput schema / properties / restart / description
      Added value: +"Start a new analysis even if one already exists for this slide."
    • addedInput schema / properties / wait_seconds / description
      Added value: +"How long to wait for the result; if it isn't ready, get_slide_analysis reads it later."
  2. Addedv0.8.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false and idempotentHint=true, but the description goes well past that: it discloses asynchronous background execution, that a running analysis is reused rather than duplicated, restart semantics, wall-clock estimates (~40s/tile with cell types, ~15x longer, a minute of model warm-up), and a licensing/research-use caveat on the PanNuke weights.

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 action and the wait contract, then cost/tradeoff guidance — a sensible ordering for an agent. It loses a little to redundancy, since the tissue-finding and tile-sampling mechanics are explained twice in overlapping paragraphs.

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 six-parameter, long-running, expensive pipeline with an output schema present, the description covers timing, cost, defaults, resumption and licensing — everything needed to call it correctly and set agent expectations. Return-value detail is properly left to the output schema.

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; the description earns above that by supplying concrete quantities the schema omits — 256x256 um tiles at 40x, the 3,000-tile / ~200 mm2 ceiling for full coverage, and the 12 vs 16 max_tiles defaults tied to cell_types. It does not add cost or format detail for wait_seconds beyond what the schema already states.

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?

Opens with a specific verb and resource ('Analyse a whole-slide image') and immediately scopes it as a background operation with a bounded wait. It is cleanly separable from siblings like detect_nuclei, classify_cells, check_image_quality and get_slide_analysis, which each cover a subset of what this composite pipeline does.

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?

Explicitly contrasts the two coverage modes by cost and output ('sample' in a few minutes vs 'full' with heatmap, longer for big resections), states the cell_types default flips between modes, and tells the agent exactly what to do if the wait expires ('call get_slide_analysis later') and how to force re-analysis (restart=true).

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