Skip to main content
Glama
unige-biochem

abba-mcp

Official
by unige-biochem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

fiji_module_run

Run Fiji/ImageJ modules, commands, menus, or Groovy scripts with JSON inputs, without opening dialogs, and return status, outputs, warnings, and errors. Start Fiji automatically and track long jobs.

Instructions

Run a module (command class, menu path, title, or the path of a script file) with inputs as a JSON object, e.g. {"sigma": 2, "image": "blobs.gif"}. Never opens the module's dialog: inputs not given keep their default; an object input with one live instance is bound to it, else pass its name (see fiji_objects). Returns status, outputs (objects by name, pictures as images), new objects, the modules it ran in turn (nested), and the warnings and errors it logged (messages). status is error when the module threw or reported success = false (error says why), canceled, or ok; ok with logged_errors (their number) and first_error means it ended normally but logged errors: check its outputs. Waits up to wait_seconds (default 30, at most 40: clients abort requests after about 60 s; follow a longer run with fiji_module_status). A run still going returns its job id, status running, and the titles of the modal dialogs open (dialogs); blocked_by_dialog means the job itself waits for a dialog. Starts Fiji first if it is not running: the first start downloads Fiji and ABBA and takes minutes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYescommand title, menu path, class name, or script file path
inputsNoJSON object of input values by name, e.g. {"sigma": 2}; inputs not given keep their default
wait_secondsNoseconds to wait for the result before returning the job id (default 30, at most 40: clients abort requests after about 60 s; follow a longer run with fiji_module_status)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only supply readOnlyHint=false/openWorldHint=false, and the description carries the full behavioral burden well beyond that: no dialog is shown, one-live-instance object binding, the full status taxonomy (error/canceled/ok plus logged_errors), job id and dialog states (running, blocked_by_dialog), and the multi-minute first-start download side effect. This is exactly the extra context the annotations lack.

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?

The core action is front-loaded in the first sentence and the dense remainder is largely justified by the tool's complexity (status semantics, job handling, cold start). It is comma-heavy and clause-dense, so a reader must work harder than ideal, but few sentences are truly expendable.

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 must describe returns, and it does so thoroughly: status, outputs (objects and images), new objects, nested modules run in turn, warnings/errors, and the running-job shape. An agent has everything needed to call this correctly and interpret the result.

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 baseline is 3, but the description adds real meaning: the valid id forms, the JSON-object shape of inputs with a concrete example and the default-preservation rule, and the rationale for the wait_seconds ceiling (clients abort after ~60 s). That exceeds what the schema fields alone convey.

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?

The description opens with a specific verb ('Run') and resource ('a module') and immediately enumerates the accepted id forms (command class, menu path, title, script file path). It also names siblings (fiji_objects for object binding, fiji_module_status for longer runs), so an agent can distinguish it from neighbors without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear operating context: the module's dialog is never opened, omitted inputs keep defaults, calls block up to wait_seconds and should be followed with fiji_module_status for longer runs. It does not, however, clarify the overlap with fiji_module_run_script, which also appears to accept a script file path, leaving a genuine when-to-use ambiguity.

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