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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one meaningful trait beyond the name — that existing annotations are preserved rather than replaced — but says nothing about whether the call is idempotent, what happens on invalid geometry, or any duplicate/overlap handling.

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

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

A single front-loaded sentence with no filler; the append-and-preserve semantics come first and nothing is wasted.

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

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

An output schema exists, so return values need not be described, but for a mutation tool with zero annotation coverage the definition leaves prerequisites, coordinate expectations, and failure behavior unstated. The nested schema fills much of the parameter gap, keeping this at an adequate rather than inadequate level.

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

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

Top-level schema coverage is 0%: image_id and annotations carry no descriptions, and the description adds no information about the image identifier format or the annotation list. The nested AnnotationInput type is well documented inside the schema, but the description contributes nothing to compensate.

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

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

The description gives a precise verb and resource ('Append annotations to an image') and its clause 'keeping the existing ones' implicitly separates it from the sibling replace_annotations. It stops short of naming that alternative explicitly, but an agent can still tell the two apart.

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

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

Usage is only implied: 'keeping the existing ones' hints that this is the right tool when prior annotations must survive, but there is no explicit when-to-use, when-not-to-use, or named alternative (replace_annotations, remove_annotations) to route the agent.

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

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

No annotations are provided, so the description carries the behavioral burden. 'Export' implies a non-destructive read, and it usefully narrows scope to polygon and circle annotations, but it never states that no data is modified, whether output is returned inline or written to a file, or any permission requirements.

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

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

A single tight sentence that front-loads the operation and resource before the output formats. No filler or redundancy.

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

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

An output schema exists, so return structure need not be explained. The description covers scope and format options adequately for a two-parameter export tool; only the file-vs-inline delivery behavior is left unstated.

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

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

Schema description coverage is 0%, so the description must compensate. It spells out the two format options as 'COCO JSON or YOLO', adding meaning beyond the bare enum values, but says nothing about image_id (self-evident by name) or format defaults.

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

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

States a specific verb (export), resource (annotations), content scope (polygon and circle), and destination formats (COCO JSON, YOLO). An agent can distinguish this from add_annotations/replace_annotations/remove_annotations by the export verb. It does not name a sibling explicitly, but the operation is unambiguous.

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

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

No when-to-use guidance, no prerequisites, and no mention of when another sibling (e.g. get_image) would be preferred. 'Same as the web app's export' hints at parity but gives no selection criteria for an agent choosing among the seven sibling tools.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the viewing URL is signed and expires in 24h, which is non-obvious time-sensitivity context. However, it says nothing about the read-only nature of the operation, permission requirements, or error behavior when the id is unknown.

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

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

A single sentence that front-loads the action and lists the payload without filler. Every clause earns its place.

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

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

An output schema exists, so the return shape need not be restated, and the description already summarizes the payload. For a simple read-by-id tool with one required parameter, this is nearly complete, with only permission/auth context missing.

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

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

Schema description coverage is 0% and the single image_id parameter is undocumented in the schema. The phrase 'one image's' implies the parameter identifies a singular image, giving minimal compensation, but no format or source for the id is given. Baseline is low, and the description only marginally fills the gap.

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

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

States a specific verb (get) and resource (one image) and enumerates exactly what is returned: metadata, all annotations, and a signed viewing URL. This cleanly distinguishes it from siblings like list_images (plural listing) and update_image_metadata (mutation).

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

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

Usage is only implied: fetch a single image by id. There is no explicit statement of when to prefer this over list_images or when it is not applicable, and no prerequisites are mentioned. Adequate but leaves routing to inference.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that results are summaries and that annotations/viewing URL require get_image, and that category filtering is case-insensitive, but it omits read-only safety, authentication needs, pagination, and rate limits. Adequate but not rich behavioral context.

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

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

Two short sentences, front-loaded with the action and scope, followed by the alternative to get_image. No filler; every clause adds information.

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

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

An output schema exists, so return values need not be detailed, but the description still usefully notes that results are summaries. It covers the only parameter and the key alternative (get_image). Missing pagination/auth details are minor for a simple list tool.

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

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

Schema coverage is 0%, so the description must define the sole parameter. It clarifies that category is optional and case-insensitive, adding filtering semantics beyond the schema's bare string/null type. It stops short of describing exact vs. partial matching or allowed values.

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

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

States a specific verb and resource ('List images saved in Image Label') plus the optional category filter. Explicitly distinguishes itself from get_image by noting it returns summaries while get_image provides annotations and the viewing URL. An agent can identify its role without opening the schema.

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

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

Gives a clear routing rule: 'use get_image for annotations and the viewing URL,' which tells the agent when this tool is insufficient. Establishes that this is for listing/summaries and optional category filtering, but does not discuss other siblings or when-not-to-use conditions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether removal is permanent, what happens if an id is not present on the image, whether the whole image annotation set is rewritten, or what permissions are needed — significant gaps for a mutation tool.

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

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

A single tight sentence with the action and the scoping identifiers front-loaded; nothing redundant or padded.

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

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

An output schema exists so return values need no explanation, but for a destructive mutation with no annotations and 0% schema coverage, the description omits reversibility, failure behavior for unknown ids, and its relationship to the other annotation-mutating siblings.

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

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

Schema description coverage is 0%, so the description must compensate. It loosely identifies both parameters — 'from an image' maps to image_id and 'by their ids' maps to annotation_ids — but adds no format, cardinality, or validity constraints beyond the field names.

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

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

Specific verb ('Remove') plus resource ('specific annotations from an image') and the identifier mechanism ('by their ids'). It does not differentiate itself from the close siblings add_annotations and replace_annotations, so an agent must still infer which mutator applies.

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

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

No when-to-use guidance is given. The description never states how this differs from replace_annotations (which also alters the annotation set) or add_annotations, so the agent gets no explicit routing rule among near-identical siblings.

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

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

No annotations are supplied, so the description carries the full disclosure burden, and it does surface the single most important trait: this is a destructive full-overwrite of all existing annotations, with an empty list as the documented clearing path. It stops short of mentioning permission requirements, atomicity, or error behavior on a bad image_id.

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

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

Two short sentences, zero padding, and the destructive scope is front-loaded ahead of the clearing tip. Every sentence earns its place.

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

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

An output schema exists, so return values need not be explained, and the description covers purpose plus the destructive/clearing semantics for a two-parameter mutation tool. The remaining gap is the undocumented image_id parameter and absence of any failure-mode context.

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

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

Top-level schema coverage is 0% (image_id and annotations carry no descriptions), so the description must compensate. It clarifies that 'annotations' is a complete replacement list and that an empty list is a valid, meaningful value — useful information the schema does not convey — but it says nothing about image_id or how it relates to the sibling tools.

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

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

States a specific verb and resource ('Replace ALL annotations on an image') with an explicit scope qualifier ('ALL') that inherently contrasts with the additive/removal semantics of the sibling tools add_annotations and remove_annotations. It does not name any sibling explicitly, so it falls just short of the top band.

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

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

The description gives one useful usage rule — 'Pass an empty list to clear them' — which is effectively an alternative to remove_annotations. However, it never states when to choose this tool over add_annotations or remove_annotations, nor any prerequisite (e.g. the image must already exist), so guidance remains implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one meaningful behavioral trait — omitted fields are preserved — which tells the agent this is a partial rather than whole-object update. But for a mutation tool it says nothing about permissions, validation of category/sub_category values, or reversibility.

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

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

Two short sentences that are front-loaded with the action and immediately follow with the key partial-update rule. No filler or redundancy.

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

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

An output schema exists, so return values need not be explained. The description covers the mutable fields and the update semantics; the main remaining gap is the unmentioned required image_id and any constraints on the free-form category fields.

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

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

Schema description coverage is 0%, so the description must compensate. It names four of the five parameters (name, category, sub-category, description) and implies each is optional via the 'omitted fields' clause, but it never mentions image_id, the sole required parameter, and adds no format or constraint detail beyond the field names.

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

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

States a clear verb (Update) and resource (an image's metadata) and enumerates exactly which fields can change. No sibling tool does the same thing (add_annotations/replace_annotations target annotations, not image metadata), so differentiation is implicit rather than stated.

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

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

The sentence 'Omitted fields are left unchanged' communicates partial-update semantics, which is useful invocation context. However, there is no explicit when-to-use guidance, no mention of prerequisites (e.g., valid image_id), and no routing against the annotation-related siblings.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the path is server-local rather than client-local, which matters for invocation, but says nothing about duplicate names, overwrite behavior, permissions, or size limits. An output schema exists, so return values need not be explained.

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

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

A single front-loaded sentence with no filler, and the parenthetical scoping note earns its place. It is arguably too terse given the undocumented parameters, but the sentence itself is efficient.

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

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

For a 4-parameter tool with 0% schema coverage and no annotations, the description covers only one parameter's semantics. Missing details about naming, categorization, and re-upload/overwrite behavior leave real gaps, though the output schema covers return values.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate. It clarifies only 'path' (local to the server machine) and leaves 'name', 'category', and 'description' entirely unexplained, including whether name defaults to the filename or whether category is free-form.

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

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

States a specific verb (upload) and resource (local image file) and clarifies the path refers to the machine running the server, which is genuinely useful. It does not explicitly distinguish itself from siblings, but upload is naturally distinct from list/get/update/annotation tools.

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

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

No statement of when to use this tool, when not to, or what alternatives exist (e.g., update_image_metadata for existing images). Usage is only inferable from the name and the upload verb.

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