Loading ToolBench
MCP server for Starlink Enterprise API integration. Manage your Starlink terminals through Claude AI using the Starlink Enterprise API
The server provides 9 tools with explicit schemas and descriptions. Naming is consistent (verb-first: list_, get_, check_). Descriptions are present but vary in quality, most are 50-120 characters (below the 194-char baseline for A+ tools). All tools are READ_ONLY, which is correct for this domain. Input schemas are properly typed with JSON Schema. However, output schemas are not documented, and error handling is minimal. Parameter descriptions are present but sparse (e.g., 'User terminal ID' lacks context on format expectations). The server lacks tool annotations (readOnlyHint, idempotentHint), per-request _meta logLevel, and structured recovery guidance. This is a competent but baseline implementation, it functions, but falls short of production-grade agent tool standards.
Check if Starlink service is available at a specific location
Get details about a specific service address
Get data usage statistics for a service line over a date range
Get details about a specific service line including subscription status and plan
Get detailed information about a specific user terminal including hardware info and configuration
Get real-time telemetry data for a terminal (uptime, signal quality, obstructions, throughput)
Output schemas not documented. LLMs cannot determine what fields to expect from tool responses, forcing them to infer structure or attempt error-prone parsing.
Tool annotations missing. No readOnlyHint, idempotentHint, or destructiveHint declared. Agents cannot determine which tools are safe to retry or which have side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List all service addresses associated with your account
List all your Starlink service lines (subscriptions/accounts)
List all your Starlink user terminals with their current status
Parameter descriptions are minimal (5 - 20 chars). E.g., 'User terminal ID (UUID format)' lacks guidance on when to use this tool vs. list_user_terminals, or what to do if the ID is unknown.
No error handling or recovery guidance. The code catches exceptions and wraps them in generic Exception messages (e.g., 'Starlink API error (400):'). LLMs receive no guidance on retryability, user-fixability, or next steps.
Pagination result limits not enforced or documented. list_user_terminals and list_service_lines accept a default page_size of 50 and max 100, but the tool descriptions do not state the result limit or warn about truncation.
No dependency hints or sequencing guidance. For example, get_terminal_details requires a user_terminal_id, but the tool description does not guide users to call list_user_terminals first if they do not have an ID.