FusionVisionMCP

Overview Schema Source Related Servers Discussions Admin

batch_analyze_images

Run one vision operation—caption, OCR, object detection/counting, or Q&A—across multiple images in a single call. Isolates per-image failures so the rest of the batch completes.

Instructions

Run one operation across many images in a single call.

The batch form of caption, ocr, detect_objects, count_objects, dense_region_caption and query_image -- pick which with operation. Use it when the same question applies to a whole set of images, since it costs one round trip instead of one per image and loads each model once for the whole run.

Failures are isolated per image: a missing file or an unreachable URL is reported as its own {"src", "success": false, "error"} entry and the rest of the batch still runs. Results come back in the order given.

For a single image, call the named tool directly -- its arguments are checked up front rather than depending on operation.

Input Schema

TableJSON Schema

Name	Required	Description
`srcs`	Yes	File paths or URLs of the images to process.
`question`	No	Required when operation is 'query'.
`operation`	Yes	One of: 'caption', 'ocr', 'detect', 'count', 'dense_caption', 'query'. Use 'query' (with `question`) rather than 'ocr' for watermarks, logos, signage, or stylized/cursive text -- 'ocr' misreads that kind of text confidently. Use 'count' (with `object_name`) rather than 'detect' for 'how many' -- 'detect' returns regions, which are not a tally.
`object_name`	No	Required when operation is 'detect' or 'count'.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.2Sep 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and handles it well. It discloses per-image failure isolation, the error entry shape, that remaining images still run, and that results preserve input order. These are non-obvious behaviors that materially affect how an agent uses the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is front-loaded with the core action, then efficiently covers use cases, failure semantics, ordering, and the single-image alternative. Every sentence contributes distinct information without redundancy.

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?

Given the rich output schema and detailed parameter schema, the description covers everything an agent needs: what the tool does, when to use it, how failures behave, result ordering, and when to prefer a sibling. No critical operational context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already explains operation choices, the question requirement, and object_name requirements. The description mainly restates that operation selects the underlying behavior rather than adding new per-parameter meaning, so the baseline 3 applies.

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 states a specific verb and resource: 'Run one operation across many images in a single call.' It explicitly positions the tool as the batch form of six named sibling tools and makes the selection mechanism ('pick which with operation') immediately clear.

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?

It gives explicit when-to-use guidance: when the same question applies to a whole set of images, to save round trips and model loading. It also gives an explicit when-not-to-use rule: for a single image, call the named tool directly, because its arguments are checked up front.

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

Deploy Server