cluster_sites_by_latency
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): dete...
This record as markdown: /tools/cloud-dchub-mcp-server/cluster-sites-by-latency.md
What cluster_sites_by_latency does on Mcp Server
AI agents call cluster_sites_by_latency to retrieve information from Mcp Server without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
sites | string | — | Semicolon-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:ashbur |
candidate_ids | object | — | Array (or comma-separated string) of candidate_id values from get_refined_queue — each resolves to its FROZEN mint coordinates (zero transcription drift); expir |
max_latency_us | number | — | Round-trip latency budget in microseconds (default 1000 µs = 1 ms; sync replication is typically 1000-2000 µs) |
min_confidence | string | — | Minimum evidence tier a pair must meet to count as viable: "published" | "tracked" | "inferred" (default inferred = include all) |
Parameters from the server's own tool schema.
Why cluster_sites_by_latency is rated Low
Tool analyzes and returns latency clustering information without modifying, deleting, or executing external operations.
From the tool's definition returns viable low-latency clusters, pairwise RTT floors, deterministic pruning
Attacks that exploit this kind of access
The rule that runs cluster_sites_by_latency safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Mcp Server, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For cluster_sites_by_latency, this is the rule to start with:
cluster_sites_by_latency is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Mcp Server, apply this rule, and every cluster_sites_by_latency call is checked against it from then on.
Questions about cluster_sites_by_latency
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. It is categorised as a Read tool in the Mcp Server MCP Server, which means it retrieves data without modifying state.
cluster_sites_by_latency accepts 4 parameters: sites, candidate_ids, max_latency_us, min_confidence. The full parameter table on this page comes from the server's own tool schema.
Register the Mcp Server MCP server in PolicyLayer and add a rule for cluster_sites_by_latency: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp Server. Nothing to install.
cluster_sites_by_latency is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the cluster_sites_by_latency rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for cluster_sites_by_latency. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
cluster_sites_by_latency is provided by the Mcp Server MCP server (https://dchub.cloud/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Mcp Server, and thousands of servers like it.
This server
Across the catalogue