Loading ToolBench
MCP server exposing a napari viewer through a child Jupyter kernel for AI agents to perform image analysis
biopb-mcp defines 10 tools with basic descriptions and input schemas, but falls short of production quality. Tool names follow verb_noun convention (start_kernel, execute_code, take_screenshot), which is good. However, descriptions are inconsistent in depth, some are adequate (execute_code: 127 chars), others minimal (status: 95 chars). Critical gaps: NO parameter descriptions visible in the schema (all params lack 'description' fields), NO output schemas documented, NO error handling guidance, NO tool annotations (readOnlyHint/destructiveHint). The execute_code and submit_job tools accept arbitrary Python code, high-risk operations that should have explicit warnings and recovery guidance in descriptions. Schemas present but incomplete: parameters have types but zero descriptions, violating the 'every parameter needs a description' rule. No evidence of idempotency hints, confirmation patterns, or rate-limit guidance for destructive operations.
Cancel a running or queued job
Execute arbitrary Python code in the napari kernel; returns inline result or job handle for long-running operations
Inspect a Python object in the kernel namespace (type, docstring, attributes, methods)
List all submitted jobs and their statuses
Poll the status of a submitted job (returns result when complete, or status if still running)
Hard-restart the napari kernel (recovers from failures; closes and reopens the viewer)
Start the napari kernel (call once at session start or to recover after failure)
No parameter descriptions in any tool schema. All 10 tools have input parameters (e.g., 'code', 'job_id', 'path') with type definitions but zero description text. LLMs cannot infer parameter meaning from names alone, 'path' could mean file path, object path, or URL path.
No output schemas documented. Tools return results but LLMs have no schema to understand response structure. E.g., execute_code returns 'inline result or job handle', what fields? What type? Agents cannot plan downstream calls without this.
High-risk operations (execute_code, submit_job, restart_kernel) lack error handling guidance and confirmation patterns. Arbitrary Python execution is irreversible, descriptions should warn of consequences and guide recovery. No dry-run or confirmation step offered.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Report kernel status: dask scheduler, distributed workers, tensor server connection, kernel uptime
Submit a long-running job to the kernel job queue (returns job ID immediately)
Capture a screenshot of the napari viewer canvas
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Risk levels are declared in the spec (READ_ONLY, WRITE, IRREVERSIBLE) but not exposed to LLMs via tool metadata. Agents cannot distinguish safe from dangerous operations.
Parameter 'path' in inspect tool lacks format guidance. Is it 'viewer.layers[0]'? 'client.query_sources'? Dot notation? Bracket notation? Description says 'e.g. viewer, client.query_sources' but LLMs often treat examples as the only valid options.