Status Observer MCP
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statusA | Check the operational status of major digital platforms, read from each vendor's official status API. Covers AI providers (Anthropic, OpenAI, Gemini), clouds (GCP, Cloudflare, DigitalOcean, Vercel, Netlify, Supabase) and developer or workplace tools (GitHub, Docker, npm, Slack, Atlassian, Discord, Dropbox, Twilio, Asana, Reddit, LinkedIn, Amplitude). |
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 1 tool
With only a single tool, there is no possibility of confusion or misselection between tools. The one tool's purpose is unambiguous.
The lone tool 'status' is a simple, readable noun name. There is no naming pattern to violate, though it does not follow a verb_noun convention.
A single tool for a status-checking service is thin but arguably sufficient since it is a read-only fetch. It covers many vendors under one operation, making the surface borderline minimal.
The tool covers a broad set of vendors' status APIs, fulfilling the core domain purpose. However, it lacks operations for filtering by vendor, incident history, or per-service detail, which are minor gaps.