Clarke GEO registry

clarke_list_deltas

On-ingest change feed for GEO slot occupancy, FCC rows, and disputes (Slot Index delta feed, edition 2). coverage is bootstrap when fewer than two registry snapshots are stored, and ingest_deltas once a later snapshot exists. Each change has slug, longitude when available, detectedAt, source vintage, before and after, and provenance. Occupancy changes are enter, leave, authority_flip, and tle_epoch. tle_epoch is a TLE epoch change or a 45 day stale transition on a TLE used for occupancy. Bootstrap does not invent occupancy history. FCC changes are new, lapsed, licensee, status, and as_of when a snapshot does not store parsed workbook rows. When both snapshots store parsed data/ssal.xlsx rows, filing diffs for that interval are new, removed, and changed. removed is a call sign that left the workbook. changed is the same call sign with a different orbital location, satellite name, licensee, administration, service, frequency range, in-orbit date, grant status, or notes. Dispute changes are appear, clear, and kind. ITU filings are not in this product. ITU Space Explorer is the current ITU source. SNS Online shut down in January 2025. TLE longitude is a tracked position, not an FCC or ITU assignment. satellite_relocated rows are not occupancy changes. Optional filters: slug, domain (occupancy, fcc, dispute), since (exclusive ISO-8601 UTC). The public page keeps at most 40 changes and about 48 KB of change JSON. A timestamp with many rows is split. truncated is true when more changes matched. Pass after from nextAfter to continue. since stays an exclusive time filter. nextSince is set only when the page ended on a timestamp boundary.

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": "clarke_list_deltas"
  }
}

Input Schema

Name	Required	Description
`slug`	No	Registry or FCC slug, e.g. '101w' or '101-2w'
`after`	No	Exclusive change id from nextAfter
`since`	No	Exclusive time filter. ISO-8601 UTC or YYYY-MM-DD HH:MM:SS
`domain`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026
- addedInput schema / properties / since / maxLength
```
Added value: +40
```
- changedInput schema / properties / slug / pattern
```
Previous value: -"^[a-z0-9-]+$"New value: +"^[a-z0-9-]{1,64}$"
```
First observedOct 22, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: page limits (40 changes, ~48 KB), truncation flag, timestamp-splitting, nextAfter/nextSince semantics, and the important caveat that bootstrap does not invent occupancy history. These are non-obvious behavioral traits an agent needs.

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?

The purpose is front-loaded, but the body is a dense wall of text mixing change-type enumerations, unrelated facts (SNS Online shutdown, ITU sourcing), and pagination rules. Some sentences (e.g., the ITU/SNS asides) don't earn their place for the caller.

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?

For a complex feed with no output schema and no annotations, the description covers the change record fields, the three domains' change kinds, and the pagination contract. It is close to complete, though the unstructured wall of text leaves some field-level detail implicit.

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 coverage is 75% and the description adds real meaning: since is exclusive ISO-8601 UTC, after comes from nextAfter, and it lists the domain values. The slug parameter is only lightly touched (pattern and meaning mostly live in the schema), keeping it at a 4.

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 description clearly states this is an on-ingest change feed covering GEO slot occupancy, FCC rows, and disputes, with the resource and scope precisely defined. It doesn't explicitly contrast against the get_slot/list_slots siblings, which is why it's a 4 rather than a 5.

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 explains the two coverage modes (bootstrap vs ingest_deltas) and their triggering conditions, and gives concrete continuation instructions ('Pass after from nextAfter to continue', 'since stays an exclusive time filter'). It stops short of stating when to prefer this over sibling list tools, so it's a clear 4.

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

All Clarke GEO registry tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.