Skip to main content
Glama

batch_labeled_images

Generate batches of labeled CT images with answer keys for practice questions, saved to one folder with a manifest and optional one-image-per-case selection.

Instructions

Run many labeled_image requests into one folder with a manifest.jsonl (no base64 in the reply). With avoid_repeat_cases each image comes from a different case when possible.

Input Schema

NameRequiredDescriptionDefault
requestsYes
output_dirNo
avoid_repeat_casesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are supplied, so the description must carry behavior. It usefully discloses that output goes to a folder with manifest.jsonl, that replies contain no base64, and how avoid_repeat_cases affects case selection. It does not disclose overwrite behavior, directory creation, permissions, error handling, or return-path details for a file-writing batch operation.

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?

Two sentences, front-loaded with the core batch action and output location; no redundant restatement. It is appropriately sized for the description's role.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batch tool with nested request objects and no output schema, the description is too thin: manifest contents, output_dir behavior, file naming, and failure modes are unspecified. An agent can identify the tool but lacks enough context to invoke it safely and predictably.

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?

With only 0% top-level schema description coverage, the description must explain parameters. It explains avoid_repeat_cases and loosely maps output_dir to "one folder", and points requests to labeled_image, but does not clarify output_dir defaults or the structure and fields of each BatchRequest.

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 gives a specific action and batch scope: run many labeled_image requests into one folder, which distinguishes it from the single labeled_image sibling. It also names manifest.jsonl and the no-base64 reply behavior, so the operation is immediately identifiable.

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

Usage Guidelines3/5

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

Use is implied for many labeled_image requests rather than a single call, and avoid_repeat_cases is described. However, there is no explicit when/when-not guidance, no statement of alternatives such as labeled_image for single images, and no prerequisites.

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