Skip to main content
Glama
Viventine-Space

orbit-sentinel-mcp

by Viventine-Space
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

search_spectrum

Read-only

Find entities holding a frequency band by returning spectrum allocations overlapping a MHz range, joined to source filings and applicants; filter by agency, direction, polarization, or holder.

Instructions

Find which entities hold a frequency band. Given a range in MHz, returns spectrum allocations overlapping it, joined to the source filing and applicant — e.g. 'who is allocated 11700-12200 MHz downlink?'. Filter by agency, direction, polarization, or holder name.

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows returned (default 50, max 500). The response total is the full match count regardless of limit; rows cannot be paged, so answer counting questions from total. Output keeps the rows that fit in about 40 KB and says how many it left out
agencyNoFilter by source agency (FCC, ITU, ...)
holderNoSubstring match on the allocation holder (applicant entity)
directionNoFilter by direction (e.g. uplink, downlink)
freq_low_mhzNoLower bound of the band to search, in MHz
polarizationNoFilter by polarization
freq_high_mhzNoUpper bound of the band to search, in MHz

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.0
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default 50, max 500)"New value: +"Max rows returned (default 50, max 500). The response total is the full match count regardless of limit; rows cannot be paged, so answer counting questions from total. Output keeps the rows that fit in about 40 KB and says how many it left out"
  2. First observedv0.3.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds useful context that results are joined to the source filing and applicant. It does not describe pagination, but the schema's limit parameter already explains the truncation behavior.

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

Conciseness5/5

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

Three sentences, front-loaded with the core purpose, then the return shape, then the filters. No filler or redundancy.

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?

With no output schema, the description still conveys what is returned (allocations joined to filing and applicant) and the schema's limit field explains truncation. Minor gap: no explicit note that frequency bounds are strings or how partial overlaps behave.

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

Parameters3/5

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

Schema coverage is 100%, so all seven parameters are documented in the schema itself. The description names the filter dimensions (agency, direction, polarization, holder) but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('Find which entities hold a frequency band') and gives a concrete example query. It is clearly distinguishable from siblings like search_satellites or search_ground_stations because it targets spectrum allocations rather than assets.

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?

Provides a worked example ('who is allocated 11700-12200 MHz downlink?') and lists the filterable dimensions, giving clear context for use. It does not explicitly route to an alternative tool or state when-not-to-use, so it falls short of a 5.

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

Deploy Server

Other Tools