MCP Observatory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scanA | Use this to check if all your MCP servers are healthy. Auto-discovers servers from Claude config files, connects to each one, and verifies tools/prompts/resources respond correctly. Use with deep=true to also invoke tools and confirm they actually execute. Returns pass/fail status for every server. |
| check_serverA | Use this to test a specific MCP server before installing or after updating it. Launches the server by command, checks all capabilities, and saves a run artifact for future comparison. Example: check_server({ command: 'npx -y @modelcontextprotocol/server-everything' }). Use deep=true to invoke tools, security=true to analyze schemas for vulnerabilities. |
| score_serverB | Use this to get a quick health grade for an MCP server. Runs all checks (capabilities, tool invocation, security) and returns a 0-100 score with A-F grade and detailed breakdown across protocol compliance, schema quality, security, reliability, and performance. |
| diff_runsA | Use this to find what changed between two server checks. Compares two run artifacts and surfaces regressions (things that broke), recoveries (things that got fixed), schema drift (added/removed/changed tool parameters), and gate status changes. Essential after updating a server. |
| get_last_runA | Return the last Observatory run for a server, including handshake allow/deny from the local receipt. No hosted account required. |
| suggest_serversA | Use this when setting up a project or wondering what MCP servers to add. Scans the working directory for languages, frameworks, databases, and cloud providers, lists currently configured servers, and cross-references the MCP registry to recommend servers you're missing. |
| recordA | Use this to capture a baseline of a working MCP server. Records all JSON-RPC traffic to a cassette file that can be replayed offline (no server needed) or used to verify future versions haven't broken anything. Like VCR for MCP. |
| replayA | Use this to test a server without running it. Replays a previously recorded cassette offline and runs all checks against the recorded responses. Useful in CI or when the live server is unavailable. |
| verifyA | Use this after updating a server to confirm nothing broke. Connects to the live server, sends the same requests from a recorded cassette, and compares responses. Reports exactly what changed — added tools, removed parameters, different response shapes. |
| watchA | Use this to check a server and see what changed since the last check. Runs all checks, saves the result, and diffs against the previous run for the same target. Shows regressions, recoveries, and schema drift in one call. |
| lock_verifyA | Verify that live MCP servers still match a previously saved lock file. Detects schema drift, added/removed tools, and breaking changes. |
| get_historyC | Get health score trends for MCP servers from run history. |
| ci_reportB | Generate a CI regression report from run artifacts. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Several tools overlap heavily in purpose: check_server, scan, watch, verify, and lock_verify all validate server health and/or compare against a known state. The distinctions between live check, cassette replay, lock file verification, and run-to-run diffing are subtle and could easily cause an agent to pick the wrong tool.
All names use snake_case and mostly start with a verb, but the conventions are mixed: single-word verbs (scan, record, replay, verify, watch), verb_noun (check_server, score_server, suggest_servers), get_* (get_last_run, get_history), and non-verb (ci_report). The pattern is readable but not uniform.
13 tools is well-scoped for an observability/health-check server. Each tool adds a distinct capability: scanning, scoring, recording, replaying, verifying, diffing, watching, locking, history, and CI reporting. No obvious bloat.
The toolset covers scan/check/score/record/replay/verify/watch/lock/history/CI workflows comprehensively. Minor gaps like listing/deleting run artifacts or managing lock files directly exist, but they don't cause fundamental failures.