Skip to main content
Glama

Check contacts

check_contacts
Read-onlyIdempotent

Double-check where elements meet - set against set, at the bodies: clash (penetration), touch, gap, distance. Without b, a against itself only (b_missing says so, next tests a against its surroundings); gap and distance need b. Pairs are counted by kind; pairs lists at most 20, clash first: n_pairs counts all, n_pairs_listed this page. value_m: clash the thinnest width of the shared body along depth_axis (world [x,y,z]), not the travel that would part them; touch 0; gap and distance the shortest distance between the bodies in any direction - not a clear width along one axis. Two reinforcing bar or mesh sets are measured by their axes (source directrix): clash value_m is the depth along their common perpendicular; where a free bar end or a sharp kink decides, the body does (brep). A clash has no tolerance: any shared volume, also under tolerance_m, which only parts touch from gap; at other curved bodies (pipes, round columns) value_m can read wider than the overlap is deep. n_checked counts the pairs tested - an empty list with n_checked 0 means nothing was in reach, not "no clash". Capped per call: clash and touch run in rounds of at most 50 bodies and 625 hull-near pairs, whole hull neighbourhoods first, for up to 20 s; a pair whose hulls are apart counts in n_pairs_hull_separated. Gap and distance at most 20 pairs (more: MEASURE_TOO_LARGE; nearest has no cap); complete false: n_untested names the elements with a pair left untested, n_pairs_untested counts those pairs, never free of clashes; next tests every pair left, none twice, bound to this revision (none: narrow a or b). untested_pairs names the pairs the 20 s cut; one that alone outlasts them (pair_over_time_budget) no next sends again - its try tests it alone. coverage per set says how many elements had a testable body; partial_body: items of it failed, a pair with body_gap partial_body is a bound and its gaps unproven. Run it on new elements against their neighbours. Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_contacts"
  }
}

Input Schema

NameRequiredDescriptionDefault
aNoWhich elements: exactly one of guid, guids, set, filter; required unless cursor
bNoWhich elements: exactly one of guid, guids, set, filter
alongNoNeeds clash in kinds. Each listed clash pair gets station_ranges [{from_station_m, to_station_m, depth_m: how far b reaches into a in the section, from the outline of a}] from plumb sections square to the axis, bounds bisected to 0.01 m; none found says stations_reason (between_sections: thinner than step_m, try a smaller one). n_pairs_stationed and n_pairs_not_stationed count this page
kindsNoDefault clash and touch
cursorNoAlone: the next page of an earlier answer; bound to its revision
nearestNoWith gap or distance: per element of a only its nearest of b, exact; the rest of b lies farther by its hull. Head nearest {n_decided, n_pairs_measured}
contactsNofast: touch between two planar bodies, approximate (source mesh, no contact_area, counts_mesh); clash, gap and distance stay exact. Default exact
max_gap_mNoRequired with gap: gaps up to this are reported
show_acceptedNoPairs accepted with accept_contacts, left out of pairs and counts by default, stay in them marked acceptance accepted; n_accepted counts them either way
skip_class_pairsNoClass pairs judged harmless, e.g. [["IfcStairFlight","IfcSlab"]], exact class, either order: tested, but out of pairs and counts; skipped_class_pairs counts them per kind

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Annotations only declare read-only/idempotent/non-destructive, but the description adds substantial behavior beyond that: 20 s budget with rounds of 50 bodies and 625 hull-near pairs, a 20-pair cap for gap/distance (MEASURE_TOO_LARGE), no-tolerance clash semantics, and the caveat that value_m can exceed actual overlap on curved bodies. It also discloses failure/partial states (complete false, n_untested, untested_pairs, pair_over_time_budget, partial_body) and warns that an empty list with n_checked 0 means nothing was in reach rather than 'no clash'.

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

Conciseness3/5

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

Nearly every clause carries real information, but the text is a dense semicolon-chained wall with telegraphic fragments ('touch 0', 'clash first: n_pairs counts all'), making it slow to parse. A short structured lead followed by grouped bullets on caps, results, and paging would preserve content with far better accessibility.

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

Completeness4/5

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

With no output schema and a very complex tool, the description must carry result interpretation, and it does: it explains n_pairs vs n_pairs_listed, n_checked, coverage, partial_body, hull-separated and untested counts, and the cursor/next paging binding to a revision. It is close to complete, losing a point mainly because the compression of so many result fields into prose makes them hard to apply reliably.

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%, so the schema already documents all ten parameters in detail, which sets the baseline at 3. The description adds little parameter-specific meaning, mostly restating dependencies already in the schema (e.g. 'gap and distance need b', 'along needs clash') and focusing instead on result-field semantics such as value_m and counting fields.

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?

The opening states a specific operation on a specific resource: geometric contact testing between element sets at the bodies, enumerating clash/touch/gap/distance. The four named predicates and the 'set against set' framing distinguish it from proximity/hull siblings. The phrasing 'Double-check where elements meet' is slightly oblique but immediately clarified.

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

Usage Guidelines4/5

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

It states concrete when-to-use guidance ('Run it on new elements against their neighbours') and conditional rules ('Without b, a against itself only... gap and distance need b'). It does not name alternative siblings (check_model, find_supports) or state when not to use it, so explicit routing guidance is missing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources