orbit-sentinel-mcp

Overview Schema Source Related Servers Discussions Admin

milestone_adherence

Read-only

Query FCC satellite deployment milestone adherence under 47 CFR 25.164, filter results by call sign, classification, or orbit type, and return verified grades or aggregate summaries.

Instructions

FCC deployment milestone adherence (47 CFR 25.164): which authorized satellite systems met their deployment milestones. Grading is deliberately asymmetric — an adverse grade must be earned, a favourable grade must be labelled. 'missed' and 'met_late' appear only where a human verified a cited FCC document; otherwise the row reads 'verification_required', which asserts nothing about the operator and must not be reported as a miss. Favourable grades are never withheld, so read verification_status: 'arithmetic_corroborated' means the deployment counts independently agree — a computation, not a person, did the corroborating — and 'uncorroborated' means the arithmetic is SILENT, not that it disagrees; no favourable grade is currently contradicted by the data. computed_grade always carries the raw arithmetic even where classification withholds it. Filter by call_sign, classification, is_ngso; set summary=true for aggregate counts, which include withheld_adverse and uncorroborated_favourable.

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

Input Schema

Name	Required	Description
`limit`	No	Max rows returned (default 100, max 500). total is the full match count regardless of limit; rows cannot be paged, so narrow with call_sign, classification or is_ngso. Output keeps the rows that fit in about 40 KB and says how many it left out
`is_ngso`	No	Filter by orbit type: true for NGSO, false for GSO
`summary`	No	If true, return aggregate counts for all systems by classification, split GSO/NGSO (is_ngso false/true); call_sign, classification, is_ngso and limit do not apply
`call_sign`	No	Filter by FCC call sign (exact match)
`classification`	No	Filter by classification: met\|met_computed\|met_late\|pending\|extended\|waived\|missed\|verification_required\|not_deployment_obligation\|attribution_ambiguous\|attribution_undetermined\|unknown. 'missed_unverified' no longer exists — unverified adverse grades are now 'verification_required'

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.10.0Nov 2, 2026

addedInput schema / properties / limit

Added value: +{
+  "description": "Max rows returned (default 100, max 500). total is the full match count regardless of limit; rows cannot be paged, so narrow with call_sign, classification or is_ngso. Output keeps the rows that fit in about 40 KB and says how many it left out",
+  "type": "integer"
+}

changedInput schema / properties / summary / description

Previous value: -"If true, return aggregate counts by classification/orbit type instead of individual rows"New value: +"If true, return aggregate counts for all systems by classification, split GSO/NGSO (is_ngso false/true); call_sign, classification, is_ngso and limit do not apply"

Changed1 schema field changedv0.6.6Sep 11, 2026

changedInput schema / properties / classification / description

Previous value: -"Filter by classification: met|met_late|pending|extended|waived|missed|missed_unverified|unknown"New value: +"Filter by classification: met|met_computed|met_late|pending|extended|waived|missed|verification_required|not_deployment_obligation|attribution_ambiguous|attribution_undetermined|unknown. 'missed_unverified' no longer exists — unverified adverse grades are now 'verification_required'"

AddedJul 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say readOnlyHint=true and idempotentHint=false; the description goes far beyond that by explaining the asymmetric grading policy, the meaning of verification_status values, that computed_grade always carries raw arithmetic even when classification withholds it, and that favourable grades are never withheld. This is exactly the interpretive context an agent needs and cannot get from structured fields.

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 purpose is front-loaded and the dense policy paragraphs are high-value, but the prose is long and some clauses (the verification_status explanation) restate points already made. Given the interpretive complexity of the tool, the length is defensible but not maximally tight.

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?

There is no output schema, and the description fully compensates: it explains the returned fields (classification, verification_status, computed_grade, summary aggregates including withheld_adverse and uncorroborated_favourable), the truncation behavior, and the fact that rows cannot be paged. An agent could interpret and call this tool correctly from the description alone.

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 100%, so the baseline is 3; the description still adds value by glossing the classification vocabulary (e.g., that missed_unverified no longer exists and now maps to verification_required) and by listing which parameters summary ignores. It largely parallels the schema for limit and is_ngso, so it earns a 4 rather than a 5.

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?

It names a specific regulatory resource (FCC deployment milestone adherence, 47 CFR 25.164) and states exactly what the output represents: which authorized satellite systems met their deployment milestones. No sibling tool covers milestone adherence, and the agent can distinguish it immediately from search_satellites or get_system_status.

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 tells the agent how to narrow results (call_sign, classification, is_ngso) and when to use summary=true, plus the crucial usage rule that 'verification_required' must never be reported as a miss. It stops short of naming any alternative tool for adjacent questions, but no sibling provides comparable data, so there is little to route against.

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