Loading ToolBench
A resident MCP server for an RMS / Global Meteor Network station. Provides tools for station health monitoring, night data retrieval, and configuration management with per-client bearer token authentication and scoped policy-based authorization.
rms-mcp demonstrates solid fundamentals: all 8 tools have clear descriptions (avg 110 chars), explicit input schemas with types, and verb-noun naming (rms_status, rms_list_nights, rms_config_set). HTTP transport with stateless FastMCP and per-request auth via bearer tokens shows protocol awareness. However, output schemas are undocumented (no return type specs visible), parameter descriptions are minimal (1-2 lines), and error handling lacks recovery guidance. Security is strong (gated decorator, audit trail, scope-based authorization), but composition could be tighter, rms_config_get and rms_config_set are separate when a single parameterized tool might suffice.
Read a single RMS .config value. Scope: config.<key>.
Change a single RMS .config value (backs up first, preserves comments, never appends). Does NOT restart capture. Scope: config.<key>.
Per-detection kinematics (frame span, peak magnitude, meteor-vs-streak hint). Omit night for the most recent.
Most recent archived nights, newest first (sorted by date, not name).
Tail the current RMS log, optionally filtered to lines containing `pattern`.
Summarise one night: meteor count, FOV, recalibration status, upload bundle. Pass a night dir name; omit for the most recent.
Output schemas undocumented. No return type specifications visible for any tool. LLMs cannot infer what fields to expect (e.g., does rms_status return {state, disk_free, night, ml_filter, upload_time} or a flat list?). Breaks downstream tool chaining and forces agents to guess field names.
Parameter descriptions are minimal (1-2 lines). 'night' param says 'Night directory name; omit for the most recent' but does not explain format (YYYYMMDD? ISO date? directory path?). 'pattern' in rms_logs lacks regex/glob syntax guidance. Ambiguity forces LLM to guess valid input formats.
Error handling lacks recovery guidance. Gated decorator raises Denied(reason) but no guidance on what to do next. If rms_reprocess fails with 'Refuses the live capture night', should agent retry later, call rms_status first, or ask user? No actionable error messages.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Launch RMS reprocessing of a captured night, out-of-process under vRMS. Refuses the live capture night and won't stack jobs. Scope: reprocess.
Station health: capture/service states, disk, current capture night, ml_filter, last upload.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). rms_config_set and rms_reprocess are destructive but unmarked. Agents cannot distinguish safe reads from risky writes without parsing descriptions. Current spec (2026-07-28) expects tool annotations.
rms_config_get and rms_config_set are separate tools with identical 'key' parameter. Could be unified into rms_config(key, value=None) with optional value for read-or-write semantics, reducing cognitive load and tool count.