Aggregates the status page of Algolia to provide real-time health updates and incident alerts.
Aggregates the status page of Cloudflare to provide real-time health updates and incident alerts.
Aggregates the status page of GitHub to provide real-time health updates and incident alerts.
Aggregates the status page of Google AI to provide real-time health updates and incident alerts.
Aggregates the status page of Linear to provide real-time health updates and incident alerts.
Aggregates the status page of Netlify to provide real-time health updates and incident alerts.
Aggregates the status page of npm to provide real-time health updates and incident alerts.
Aggregates the status page of OpenAI to provide real-time health updates and incident alerts.
Aggregates the status page of Render to provide real-time health updates and incident alerts.
Aggregates the status page of Stripe to provide real-time health updates and incident alerts.
Aggregates the status page of Vercel to provide real-time health updates and incident alerts.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@status-aggregator-mcp check status of OpenAI and GitHub"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Cross-vendor SaaS status as a stdio MCP server. For AI agents deciding retry/fallback.
Probe P-003 by weiseer.
Aggregates the status pages of 14+ SaaS providers AI agents depend on (Anthropic, OpenAI, Google AI, Mistral, GitHub, npm, Cloudflare, AWS, Vercel, Netlify, Render, Stripe, Algolia, Linear) into one MCP server.
Your agent can:
list_services — list monitored providers + last-known status
get_status — full status for one provider with cited status-page URL
get_incidents_today — active incidents across all
check_all — quick health summary (counts by status)
Related MCP server: uptimepage
Agent DIY (per call) | status-aggregator | |
Status pages to fetch | 14 individual API calls | 1 MCP call |
Token cost | $0.05-0.15 | $0 free / $0.00005 paid |
Latency | 3-8 seconds | <100ms |
Schema normalization | Per-vendor parsing | Pre-normalized |
npm install -g @weiseer/status-aggregator-mcp{
"mcpServers": {
"status-aggregator": {
"command": "npx",
"args": ["-y", "@weiseer/status-aggregator-mcp"]
}
}
}STATUS_AGG_URL — override remote snapshot URL
STATUS_AGG_LOCAL_ONLY=1 — skip remote fetch
@weiseer/llm-oracle-mcp — LLM pricing + availability oracle
@weiseer/bounty-mcp — live coding-bounty deal-flow
@weiseer/api-changelog-mcp — SDK breaking-change tracker
github.com/weiseer — all weiseer services
Apache-2.0
Aggregate status counts. Quick health summary for agents deciding whether to retry/fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions 'aggregate status counts' but does not explain what is counted, whether it is read-only, or any side effects or permissions needed. Lacks important operational details for a health summary tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, very concise with no extraneous words. However, the lack of parameter explanation makes it incomplete rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and an undocumented parameter, the description provides only high-level purpose. Missing details on input, output, and behavioral contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'category' is a string with 0% schema description coverage. The tool description does not mention or explain the parameter, leaving its purpose and allowed values entirely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes the tool as providing 'aggregate status counts' and 'quick health summary', which clearly differentiates it from sibling tools like list_services, get_status, and get_incidents_today. The verb 'aggregate' and resource 'status counts' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the tool is for 'agents deciding whether to retry/fallback', giving clear context for when to use it. Does not specify when not to use or provide explicit alternatives, but the sibling tools imply other choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Active incidents across all monitored services as of snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It states 'as of snapshot' implying a read operation, but omits details about data freshness, idempotency, permissions required, rate limits, or side effects. The description is insufficient for safe agent action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) but lacks a complete sentence structure. It could be refined to a full sentence without additional length, improving readability. Currently it is a fragment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clearly explain what the tool returns (e.g., incident IDs, severity, timestamps). 'Active incidents across all monitored services' is vague and does not specify the response structure. The tool has no parameters, so the description must compensate, but it fails to do so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% (empty). The description does not add parameter-specific meaning, but with no parameters, the baseline is 4. No contradiction or missing info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Active incidents across all monitored services as of snapshot.' It identifies the tool as returning current incidents, distinct from sibling tools like list_services, get_status, and check_all. However, it is a noun phrase rather than an imperative verb phrase, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when to use, or when to avoid. The agent receives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full status record for one service, with cited status-page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| service_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions returning a URL but does not disclose what 'full status' includes (e.g., uptime, incidents), authentication requirements, or any side effects. Behavior is minimally described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with key information, and contains no filler. However, it could include more detail without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify the return structure. It mentions a URL but not other fields of the 'full status record'. This leaves the agent uncertain about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the 'service_id' parameter (e.g., format, example values). It adds no meaning beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'Full status record for one service' with a cited URL. This distinguishes it from siblings like list_services (listing all services) and get_incidents_today (incidents only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need detailed status for a specific service, but does not explicitly guide when to use alternatives (e.g., list_services for all services, check_all for aggregate). No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List monitored SaaS providers + last-known status. Filter by category or status.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | e.g. llm-provider, cloud, devtools, payments | |
| current_status | No | e.g. operational, degraded, partial_outage, major_outage |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states listing and filtering but omits details like data freshness, pagination, authentication needs, or whether results are complete. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with purpose, then filtering options. Efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too brief. It covers basic purpose but lacks detail on return format, expected output structure, or behavior for empty results. Adequate for a simple list tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described in the schema. The description restates filtering capability but adds no new meaning beyond 'filter by category or status'. Baselines at 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists monitored SaaS providers with their last-known status, and explicitly mentions filtering by category or status. The verb 'list' and resource 'monitored SaaS providers' are specific, and the distinction from siblings like get_status (likely single provider) is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_status for a single provider, get_incidents_today for incidents). No exclusions or prerequisites provided, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1check_allget_incidents_todayget_statuslist_servicesEach tool has a distinct purpose: listing services, getting detailed status, fetching incidents, and aggregate summary. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern (list_services, get_status, get_incidents_today, check_all). The pattern is uniform and predictable.
With 4 tools, the surface is well-scoped for a status aggregator. Each tool covers a necessary operation without redundancy.
Core operations are present: listing, detail, incidents, and summary. Missing historical incident queries or subscription capabilities, but reasonable for a basic aggregator.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/weiseer/status-aggregator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
