Skip to main content
Glama

Trace Connection

trace_connection
Read-onlyIdempotent

Trace how two named things in the planning record connect, and report how specific that connection is. Give from and to for the shortest route between them; give from alone to rank what one actor connects to; give neither to rank the corpus's most specific connections. Endpoints are entity, meeting, or named-pattern slugs — list_entities, list_meetings and list_patterns discover them.

Routes run over the three layers where a shared node is a specific claim: meeting attendance transcribed from agendas and minutes (250 references across 78 meeting records; a meeting record holds a median of 3 entities and at most 12), peer claims authored on an entity dossier (169 links, 47 of them stated on both dossiers), and shared named patterns (60 references across 15 patterns; a pattern holds a median of 2 entities and at most 10). That substrate is 162 nodes and 479 links over 69 entities, in one connected component. Place, corridor, brief and watch links serve here as filters and citations rather than as routes: the us-27-south-lake node alone carries 118 links, so a route through it would hold for nearly every pair in the corpus.

Hop count is a result here rather than an input. Across the full frontmatter graph, 94.5% of entity pairs already sit within two steps and a three-step expansion reaches a median of 235 of 243 nodes, so depth returns the corpus rather than an answer. What discriminates is the degree of the WIDEST node a route passes through, and the ranking leads on it: a route is only as specific as its least specific waypoint. Two more measured properties travel with every row — how many equally-short routes exist (uniqueness runs 64% at two hops, 41% at three, 16% at four), and whether the two endpoints are minuted in disjoint jurisdictions, which 15 of 69 entities are positioned to be. interior_degrees carries every degree on the chain so you can re-rank on any of them, and provenance says whether the whole join rests on the meeting record, on a curator’s hand, or on both.

Filter with evidence to choose which layers may carry a hop, crossing to keep only pairs minuted in different jurisdictions, and exclude_published to keep only pairs the observatory’s own briefs have not already put together. Every response reports how many of the 2,346 possible entity pairs the filters matched, splits them by provenance, and accounts for the rest — so a query that discriminated nothing says so in its own output. Note one interaction the response also states: two entities minuted in one room share that room’s jurisdiction, so crossing: "jurisdiction" holds no two-hop minuted route, and the minuted routes that satisfy it run three hops or more.

What it leaves undetermined, stated on every call: vote outcomes and dispositions, which live in meeting prose and item tables; direction and sequence, since a route is co-occurrence in a record; and the 298 of 376 meeting records not yet linked to an entity, where what the tool covers is what has been curated. In from and sweep modes, rows that share a chain of intermediaries collapse to one finding, which names the rest of its roster in route_also_joins. Pair with describe_entity for a node’s full dossier, describe_meeting for the room itself, and semantic_search for prose.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoThe other endpoint, drawn from the same three vocabularies as `from`. Supplying `to` without `from` is accepted and read as `from`, because the graph is undirected; the response echoes that as query.normalized_as.
fromNoOne endpoint slug, resolved in order against entities, meetings, then named patterns — the three vocabularies in which a shared node is a specific claim. No slug is shared between them on the deployed corpus, so a bare slug resolves unambiguously and needs no type prefix (e.g., "tara-tedrow", "minneola-pz-2025-01", "self-storage-canary"). Omit both endpoints to rank the whole corpus.
limitNoHow many connections to return. It caps connections; routes within one connection are shown five at a time in pair mode and one at a time in from and sweep modes, and `routes_shown` beside the exact `shortest_path_count` names how many. A value outside 1–25 is refused rather than clamped, so selectivity.returned always agrees with what you asked for.
crossingNo"any" ranks every matching pair. "jurisdiction" keeps only pairs whose record-backed jurisdiction footprints are disjoint and both present — computed from the jurisdiction on each minuted meeting rather than from an authored place list.any
evidenceNoWhich layers may carry a hop. "minuted" = attendance transcribed from an agenda or minutes; "authored" = a peer claim stated on an entity dossier; "named_pattern" = two entities listed as exhibits of one named pattern. This is the substrate choice and the largest single lever on the answer: a restricted set fragments the graph (minuted alone is 6 components), and the response reports substrate.components and a fragmentation note rather than returning a bare no_path.
exclude_publishedNotrue keeps only the pairs the observatory's own briefs have yet to put together — tested against the union of an entity's appears_in_briefs and the briefs that name it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
limitsYesAssembled per call. The coverage line is always first: absence in this tool is absence of curation.
no_pathNoPair mode only, when the endpoints are unreachable on the chosen layers. Null everywhere else, including in pair mode when a route exists.
rankingYesThe sort rule, verbatim, labelled a judgement call. Every integer behind it is in each row.
coverageYesWhat the corpus covers, plus what the graph covers: meetings linked to entities against meetings in corpus, jurisdictions linked against jurisdictions in corpus, and the per-jurisdiction breakdown.
tie_noteNoA sentence, present when the cut at `limit` lands inside a band of connections that tie on widest-node degree, hop count and path count — naming the band, its size, and that order within it falls back to slug.
substrateYesThe graph the routes ran over, for the evidence layers this call selected.
calibrationYesMeasured background rates for the chosen evidence layers — what to read a row against.
connectionsYes
selectivityYesHow much of the population the filters kept — the tool grading its own discrimination.
declared_directNoFrom and sweep modes: one-hop authored pairs, unscored, as slug pairs — describe_entity already returns each one in its dossier context.
declared_direct_noteNoPresent whenever declared_direct carries a row: the call that reads any of them in full.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: hop count is a result not an input, ranking leads on the widest node's degree, uniqueness rates at different hop counts, the crossing:jurisdiction interaction (two entities minuted in one room share jurisdiction, so no two-hop minuted route), and the collapse of shared-intermediary rows in from/sweep modes. It also discloses what the tool leaves undetermined on every call. This is rich, non-redundant behavioral disclosure.

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 sentence earns its place: it packs mode semantics, substrate statistics, ranking logic, filter interactions, and limitations into a dense but organized structure. It is front-loaded with the core purpose and modes, then layers in substrate details, ranking rationale, filters, and caveats. It is not concise in word count, but it is information-dense and structured; the length is justified by the tool's complexity. A 4 rather than 5 because the density is high enough that an agent must parse carefully, and some statistics (e.g., 94.5% of entity pairs within two steps) could be trimmed without losing essential guidance.

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?

The tool has 6 parameters, 0 required, 100% schema coverage, an output schema, and rich annotations. The description covers invocation modes, endpoint vocabularies, filter semantics, ranking behavior, output properties (interior_degrees, provenance, route_also_joins, routes_shown, shortest_path_count), and known limitations. It even explains how the response reports matched-pair counts and accounts for non-matching pairs. For a tool this complex, the description is complete enough for an agent to select and invoke it correctly without opening the output schema.

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%, so the baseline is 3. The description adds meaning beyond the schema: it explains the resolution order for slugs (entities, meetings, then named patterns), clarifies that supplying `to` without `from` is accepted and normalized, explains that `limit` caps connections but routes within a connection are shown five at a time in pair mode and one at a time in from/sweep modes, and describes the fragmentation effect of restricting `evidence` (minuted alone is 6 components). It does not add much for `crossing` or `exclude_published` beyond the schema, but the added context for the trickier parameters justifies a 4.

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 ('Trace'), a clear resource ('how two named things in the planning record connect'), and an explicit statement of what the tool reports ('how specific that connection is'). It distinguishes three modes (from+to, from alone, neither) and names sibling tools (list_entities, list_meetings, list_patterns) for discovering endpoints, so an agent can tell it apart from describe_* and semantic_search tools.

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 when-to-use guidance: it names the endpoint discovery siblings, explains the three invocation modes, and closes with 'Pair with describe_entity for a node's full dossier, describe_meeting for the room itself, and semantic_search for prose.' It also states what the tool does NOT determine (vote outcomes, direction/sequence, uncurated meetings), which is exclusionary guidance that prevents misuse.

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