peerglass_satellite_connectivity

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

Annotations indicate readOnly/idempotent/non-destructive operations. Description adds valuable behavioral context beyond annotations: specifies the six satellite providers monitored, explains the ground-shutdown scenario where satellite remains available, and documents return format ('Per-provider active status and announced prefix count'). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections: purpose statement, usage context, Args, and Returns. Front-loaded with specific providers and use case. Args/Returns sections necessary given poor schema coverage. Slightly verbose but information-dense without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive for a read-only monitoring tool: annotations cover safety profile (read-only, non-destructive), description covers target providers, use case, and return value semantics. Given output schema exists (per context signals), description appropriately focuses on input parameters and behavioral context rather than output structure details. Could mention rate limits or caching behavior for perfect completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the Args section effectively compensates by documenting both parameters: clarifies country_code expects 'ISO 3166-1 alpha-2 code' and notes it is 'used for context', and specifies response_format accepts 'markdown' (default) or 'json'. Could improve by noting country_code is required, but covers essential semantics well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states specific action ('Check whether satellite internet providers... are actively announcing BGP prefixes') and lists exact providers monitored (Starlink, Viasat, OneWeb, SES, Inmarsat, HughesNet). Clearly distinguishes from sibling rir_check_bgp_status by specifying satellite-specific providers and BGP prefix announcement monitoring.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly identifies use case context ('During ground-based internet shutdowns, satellite services often remain the only available connectivity option for journalists and aid workers'), helping agents understand when this tool is valuable versus general connectivity checks. Does not explicitly name alternative tools, but contextualizes the specific humanitarian/emergency scenario where this tool applies.

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