Skip to main content
Glama

count_objects

Counts instances of a named object in an image, separating overlapping or touching items and flagging ambiguous tallies so results are reliable.

Instructions

Count how many instances of a named object an image contains.

Use this, not detect_objects, whenever the question is "how many". detect_objects returns however many regions Florence-2's grounding head emits, which is not a tally: it collapses several repeated, undifferentiated parts into one box (every petal of a flower, both halves of a fused blade) and conversely splits one object into overlapping sub-part boxes.

Returns count, plus bboxes/points/labels/scores for the instances found, index-aligned and in the same pixel-space convention detect_objects uses. scores are per-detection confidences, so a count resting on marginal detections is visible rather than implied. group_boxes_dropped counts detections that enclosed the whole arrangement rather than one instance.

Accuracy is measured, not assumed: against a fixture suite whose synthetic counts are exact by construction, this is right on 9 of 10 positive cases with a mean error of 0.1, while holding all 8 single-object controls. Separated, touching, dense, two-instance and awkwardly-named cases are reliable.

Two measured limits, worth checking before trusting a count:

Heavy overlap undercounts. Eight identical shapes in a ring count as 8 when separated or touching, but 6 once they overlap by roughly two-thirds of their width. A count below what you expect means "could not separate them", not a real tally -- and it will undercount rather than overcount.

Some evidence is simply not in the picture. On a photo of a paper flower whose petals overlap, this returns 1 at every resolution from 128px to 768px, as does every other approach tried -- other detectors, outline geometry, tiled crops, and interior-colour analysis alike. That flower's outline is 98% convex and its interior contrast is near zero, so nothing measurable distinguishes the petals. Ask query_image for a count in that situation and treat it as an estimate.

When only one region is found, a silhouette block is added measuring how many repeated lobes that region's outline contains. count and silhouette.lobes come from different methods and neither overrides the other: count: 1 beside silhouette.lobes: 8 means the detector could not separate the instances while the outline shows eight cores. agreement: true means a second, independent estimator matched it; shattered or clipped mean the number should not be used at all.

Set consensus=true (the default) for two extra fields that surface structural ambiguity instead of hiding it:

  • consensus: {detector_count, region_label_count, agree} -- a second count from Florence-2's dense region captioner (a different head), which tally how many region labels contain the object name. Agreement is real evidence; disagreement is a warning.

  • separable: "yes" if the count is a real tally (the detector separated instances, or a single region the silhouette confirms is one lobe), "no" if the detector collapsed while the outline shows several lobes (the overlapping-petal case: nothing local can count it honestly), "unknown" when there's no silhouette check to confirm either way. Read count with this in mind: a count: 1 with separable: "no" is a collapse, not a tally.

When separable is "no" but the outline still carries the lobe pattern (silhouette.by_radial > 1), an estimates block is added reporting that outline count as an actionable number -- it's a measurement (angular notches in the silhouette), not a judgment, so it stays within "measure, don't judge". count is never overwritten; estimates.outline is the number the outline supports, with a basis string saying so. Set vqa_estimate=true to also ask Moondream2 "how many ?" and attach Additionally, every result reports semantic_ambiguity (bool) and count_semantics ("measured_tally", "minimum_visible_instances", or "unverified_tally"). When semantic_ambiguity is true, an ambiguity payload is attached detailing why the count represents a collapsed or ambiguous structure rather than a confirmed discrete tally.

A maximally vague object_name ("object", "thing", "item", ...) is guarded the same way detect_objects is: Grounding DINO has the same fallback-to- the-whole-frame failure mode on a name with nothing distinctive to point to, so a near-full-frame box is dropped rather than counted as a real instance. clip_art=true gets the equivalent guard through Florence-2's own exclude_full_frame. Only the exact generic vocabulary triggers this; a specific noun that genuinely fills the frame is counted 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.
clip_artNoWhen true, count with Florence-2's grounding head instead of Grounding DINO. Grounding DINO's training distribution is real photographs; on flat vector art and iconography it can over-detect (measured on a mixed clip-art scene: 6 instead of 2 trees, and a spurious 4th house past the true 3). Florence-2 got both exactly right on the same scene. Try it when the image is clip art / flat vector style and the default count looks wrong; `scores` are unavailable on this path (Florence-2's grounding head carries no per-box confidence) and `group_boxes_dropped` is not applicable.
consensusNoWhen true (default), also tally how many `dense_region_caption` labels match the object name as an independent second opinion, and report a `separable` flag. The dense region captioner is a different Florence-2 head than Grounding DINO, so agreement between the two is real evidence and disagreement is a visible warning. Cheap -- uses the already-loaded Florence-2, no new model.
thresholdNoBox confidence floor passed to Grounding DINO (default 0.15, the value measured against benchmarks/ to hold every negative control -- see CLAUDE.md). Raise it for a visually cluttered scene with distractor shapes near the target: on one measured case (a target star among 18 muted-color distractors) the default threshold counted every distractor, while 0.5 separated the true target (score 0.90) from all of them (scores 0.19-0.32) for an exact count. This is a manual lever, not automatic -- raising it blindly on a normal scene can just as easily drop real instances, so use it once you suspect clutter, not by default.
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.
vqa_estimateNoWhen true and the detector has collapsed overlapping instances (separable is 'no'), also ask Moondream2 'how many <name>?' and attach its answer as estimates.vqa -- a judgment estimate, clearly marked, not a tally. Off by default so a session that never asks keeps Moondream unloaded.
return_annotatedNoIf true, saves an annotated image with counting boxes and returns the file path.
verify_silhouetteNoWhen the detector finds only one region, segment it and measure how many repeated lobes its outline has. Costs one SAM2 load on the first such call.
adaptive_thresholdNoWhen true, evaluates the raw detection distribution using kernel density estimation to automatically raise the threshold just above noise clusters if clear modes exist. Suppresses hundreds of false-positive sub-boxes in texture-heavy scenes while preserving real detections. Overrides manual threshold if the adaptive threshold is higher.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.2

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers extensively. It discloses measured failure modes (heavy overlap undercounts: 8 shapes count as 6 when overlapping; the paper flower returns 1 at every resolution), explains the silhouette block and that count and silhouette.lobes come from different methods and neither overrides the other, describes the consensus and separable fields, and explains the generic-object-name guard. It also discloses that scores are unavailable on the clip_art path and that group_boxes_dropped is not applicable. This is far beyond what annotations would have provided.

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 but every section earns its place: it front-loads the core purpose and sibling differentiation, then layers behavioral caveats, output semantics, and parameter-specific guidance. The structure uses clear section breaks and bolded terms. It is not concise in word count, but it is dense with actionable information and well-organized. A 4 is appropriate because the length is justified by the tool's complexity, though it could be tightened in places (e.g., the paper-flower anecdote is illustrative but slightly verbose).

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 tool's complexity (9 parameters, 2 required, no annotations, rich output schema), the description is remarkably complete. It covers when to use the tool, when not to, measured accuracy, failure modes, output field semantics, parameter effects, and even the generic-object-name guard. The output schema exists, so return values need not be fully re-explained, but the description goes beyond that to explain the meaning and reliability of the returned fields. Nothing an agent needs to call this tool correctly is missing.

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

Parameters5/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema. It explains the semantic distinction between count and silhouette.lobes, the meaning of separable values, the consensus fields, the estimates block, and the semantic_ambiguity/count_semantics fields. It also explains the generic-object-name guard and the clip_art path's lack of scores. The description enriches the output semantics far beyond what the input schema alone provides, and it clarifies how parameters like consensus, vqa_estimate, and verify_silhouette affect the output structure.

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 and resource: 'Count how many instances of a named object an image contains.' It immediately distinguishes itself from the sibling detect_objects by explaining that detect_objects returns regions, not a tally, and that count_objects is the tool to use when the question is 'how many'. This is a textbook example of purpose clarity with sibling differentiation.

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 explicitly says 'Use this, not detect_objects, whenever the question is "how many"' and explains why detect_objects is unsuitable (it collapses repeated parts and splits objects). It also provides detailed when-to-use guidance for parameters like clip_art (flat vector art), threshold (cluttered scenes), consensus (independent second opinion), and vqa_estimate (when detector collapsed). It even gives measured examples of when the tool fails (heavy overlap, low-contrast petals) and advises checking query_image in those cases. This is comprehensive usage guidance with explicit alternatives and exclusions.

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