Image Label MCP Server

Add annotations

add_annotations

Add pins, polygons, circles, rectangles, or arrows to an image without replacing existing annotations, enabling incremental labeling for training data and visual documentation.

Instructions

Append annotations to an image, keeping the existing ones.

Input Schema

Name	Required	Description	Default
`image_id`	Yes	Id of an image in Image Label: the imageId (a UUID string) returned by list_images or an upload.
`annotations`	Yes	Annotations to add (polygon, circle, rectangle, pin or arrow, in image pixels); existing annotations are kept.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.8.1Oct 28, 2026

addedInput schema / properties / annotations / description

Added value: +"Annotations to add (polygon, circle, rectangle, pin or arrow, in image pixels); existing annotations are kept."

addedInput schema / properties / image_id / description

Added value: +"Id of an image in Image Label: the imageId (a UUID string) returned by list_images or an upload."

First observedv0.1.0Oct 17, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnly=false, destructive=false and idempotent=false; the description corroborates the additive/non-destructive nature with 'append...keeping the existing ones.' It does not disclose the non-idempotent consequence (repeated calls duplicate annotations) or any validation behavior, which is the main thing an agent needs to know beyond the annotation flags.

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?

A single front-loaded sentence with zero waste; the key behavioral qualifier is in the same clause as the action.

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

Completeness3/5

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

An output schema exists and the input schema is fully described, so much is already covered. However, the description omits type-dependent requirements (polygon needs points, circle needs radius, arrow needs arrowTarget) and the duplication risk of a non-idempotent append, leaving an agent to work those out from the schema alone.

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 nested AnnotationInput documents coordinates, per-type fields and defaults, so the schema carries the parameter burden. The description adds no parameter-level meaning beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (append annotations to an image) and adds a scope qualifier ('keeping the existing ones') that implicitly separates it from replace_annotations. It could be stronger only by naming that sibling outright.

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?

The phrase 'keeping the existing ones' hints at when to prefer this over replace_annotations, but no alternative tool is named and no explicit when/when-not guidance is given. Usage must be inferred from the sibling list.

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