Skip to main content
Glama

cluster_sites_by_latency

Read-onlyIdempotent

Identify which candidate sites can form a low-latency cluster by evaluating pairwise RTT floors and estimates against your latency budget.

Instructions

Physics-bounded latency clustering for 2-8 sites — returns viable low-latency clusters and pairwise RTT floors before any routing work. Use when your human wants to know which of N candidate sites can form a synchronous / low-latency cluster (sync replication, active-active pairs, HPC pods): deterministic pruning BEFORE detailed routing. Per site pair: haversine distance, round-trip physics floor (km × 4.9 µs/km — light in SMF-28 fiber, n≈1.468 — then ×2), estimated real RTT (floor × route_factor 1.4, a stamped inference), viable vs physics_impossible against your budget, and confidence_v — the provenance tier of the supporting evidence (published | tracked | inferred). Also returns clusters: the largest site subsets whose ALL pairwise estimates fit the budget, plus each site's inferred dark-fiber screening level. CANDIDATE CONTRACT: pass candidate_ids (from get_refined_queue) instead of raw coordinates — each resolves to its FROZEN mint coordinates (zero transposition), and cand_… tokens may also be mixed into the sites string; expired/unknown ids are dropped AND declared in candidate_contract (fail-closed). Example: cluster_sites_by_latency sites="39.04,-77.48:ashburn;39.29,-76.61:baltimore;40.42,-79.99:pittsburgh" max_latency_us=2000 — or cluster_sites_by_latency candidate_ids=["cand_…","cand_…"] max_latency_us=2000. Returns _entity=latency_clusters: {pairs:[{from, to, distance_km, floor_rtt_us, est_rtt_us, viable, physics_impossible, confidence_v, endpoint_dark_screen}], clusters:[{sites, size, max_est_rtt_us}], viable_count, pruned_count, assumptions, provenance}. Do NOT treat this as an engineered latency quote — the floors are physics (no fiber path can beat them) but the estimates are inference (route_factor 1.4); always quote each pair's confidence_v when relaying results. For actual route corridors use plan_fiber_leadin; for a single-site connectivity score use get_fiber_readiness.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sitesNoSemicolon-separated "lat,lon" pairs, 2-8 sites (same format as compare_sites locations); optional per-site labels via "lat,lon:label", e.g. "39.04,-77.48:ashburn;39.29,-76.61:baltimore". cand_… tokens are also accepted here and resolve to frozen mint coordinates. Optional if candidate_ids is given
candidate_idsNoArray (or comma-separated string) of candidate_id values from get_refined_queue — each resolves to its FROZEN mint coordinates (zero transcription drift); expired/unknown are dropped and declared in candidate_contract. Use instead of, or alongside, sites
max_latency_usNoRound-trip latency budget in microseconds (default 1000 µs = 1 ms; sync replication is typically 1000-2000 µs)
min_confidenceNoMinimum evidence tier a pair must meet to count as viable: "published" | "tracked" | "inferred" (default inferred = include all)
Behavior5/5

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

The description discloses all relevant behavioral traits: it performs physics-based estimation using haversine distance and a route factor, returns confidence levels (confidence_v), and explains how candidate_ids resolve to frozen coordinates with fail-closed handling for expired/unknown IDs. This adds substantial context beyond the annotations, which already indicate readOnly, idempotent, and non-destructive behavior.

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 thorough but slightly verbose, containing multiple paragraphs. However, it is well-structured with front-loaded purpose and key usage, and every sentence adds value. Minor redundancy could be trimmed.

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?

Despite lacking an output schema, the description fully details the return structure (_entity=latency_clusters with pairs, clusters, counts, assumptions, provenance) and explains the confidence tiers. Combined with 100% schema parameter coverage, the description provides complete context for an agent to understand and use the tool effectively.

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%, but the description adds meaningful context: for 'sites', it explains the format with labels and mixing of cand_ tokens; for 'max_latency_us', it provides defaults and typical sync replication ranges; for 'min_confidence', it defines the enum values. Examples are also provided, enhancing understanding.

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 clearly states the tool's purpose: 'Physics-bounded latency clustering for 2-8 sites — returns viable low-latency clusters and pairwise RTT floors before any routing work.' It distinguishes from siblings like plan_fiber_leadin and get_fiber_readiness by emphasizing its role as a preliminary pruning step.

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?

Explicit usage guidance is provided: 'Use when your human wants to know which of N candidate sites can form a synchronous / low-latency cluster... deterministic pruning BEFORE detailed routing.' It also states when not to use: 'Do NOT treat this as an engineered latency quote' and suggests alternatives: 'For actual route corridors use plan_fiber_leadin; for a single-site connectivity score use get_fiber_readiness.'

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/azmartone67/dchub-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server