Skip to main content
Glama

detect_objects

Locate a named object in an image, returning bounding boxes, center points, and labels. Use precise object names to get reliable regions; optionally receive an annotated image.

Instructions

Locate a named object in an image, as bounding boxes and center points.

Returns bboxes ([x1, y1, x2, y2] each), points (the center of each box) and labels, all index-aligned -- so use this whether you want regions or coordinates; the centers come free with the boxes.

If return_annotated is true, the return value becomes a dictionary containing the regular results plus an annotated_image_path key.

The count of results is NOT a reliable count of objects on an ambiguous class name: Florence-2 can return several overlapping results for one physical object (a whole-animal box plus sub-part boxes all labelled 'wing'), or a single result spanning two touching instances (two fused blades labelled once as 'sword blade'). Prefer a more specific object_name, and treat results as candidates to inspect, not a tally. Use count_objects when you actually need "how many" -- it runs a detection head that emits one region per instance, which this head does not. Neither can separate heavily overlapping instances, so a count of 1 from either means "could not separate", not "there is one".

Boxes cannot answer whether two objects actually touch or whether one is inside another -- they overlap the moment one object is merely in front of another. Use spatial_relations for that.

A maximally vague object_name ("object", "thing", "item", ...) on a scene with nothing distinctive to point to gets a near-full-frame box filtered out rather than returned as a match -- Florence-2's grounding head has no explicit "nothing here" output for that case and falls back to the whole image otherwise. This only applies to the exact generic vocabulary itself: a specific noun that genuinely fills the frame (a close-up of wood, asked for "wood") is returned unfiltered.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
srcYesLocal file path or http(s) URL of the image to process. PDFs are also accepted and are rendered one image per page, so tools that return a list return one entry per page.
object_nameYesName of the object to locate, e.g. 'person', 'car', 'face'. A short noun phrase works too ('the red mug'). More specific names ground more reliably than broad ones.
return_annotatedNoIf true, returns a local temp file path to an annotated image with drawn bounding boxes.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.2

TDQS

A4.8/5.0
Behavior5/5

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, and it delivers: it discloses that the count is unreliable under ambiguous names (Florence-2 overlapping sub-part boxes, fused instances), that boxes cannot answer touch/inside questions, that a vague object_name yields a near-full-frame box that gets filtered out, and that neither tool separates heavily overlapping instances. This is rich, honest behavioral disclosure with zero annotation support.

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

Conciseness4/5

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

The description is long — four substantial paragraphs — but it is not padded. It is front-loaded with the core purpose and return format, then each subsequent paragraph addresses a distinct footgun (count unreliability, spatial limitations, generic vocabulary). The length is proportionate to the tool's genuine behavioral complexity, and every sentence earns its place. Slightly long for a first read, hence not a 5.

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?

This is a complex tool with real failure modes, and an output schema exists to document return values. The description covers the return format, the return_annotated variant, count unreliability, sibling differentiation, spatial limitations, and the vague-name edge case. Nothing an agent needs to call it correctly is missing, given the rich schema and output schema that accompany it.

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

Parameters4/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 documents src, object_name, and return_annotated well, so the baseline is 3. The description adds genuine interpretational value: it explains how object_name specificity affects grounding reliability and the return_annotated key, and it teaches the agent how to interpret the returned bboxes/points/labels (index-aligned, centers come free). This bumps it above baseline without fully re-documenting parameters.

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 opens with a specific verb-resource pair: 'Locate a named object in an image, as bounding boxes and center points.' It states exactly what is produced (bboxes, points, labels) and is clearly differentiated from siblings: it tells the agent to use count_objects for tallies and spatial_relations for touch/containment questions, so detect_objects cannot be confused with either.

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?

The description gives explicit routing guidance: 'Use count_objects when you actually need "how many"' and 'Use spatial_relations for that' for overlap/containment questions. It also advises preferring a more specific object_name and warns against generic vocabulary. The when-to-use and when-not-to-use guidance is unambiguous and names the exact alternatives.

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