Status pages and uptime monitoring: read status, monitors, incidents and error budgets, and with a write key create monitors, open incidents, post updates, schedule maintenance and record deploys.
Scored across 4 tools
get_status provides a summary snapshot including monitors and incidents, which overlaps with list_monitors and list_incidents. However, descriptions clarify that the latter provide detailed histories and per-monitor specifics, so boundaries are mostly distinct.
All tool names follow a consistent verb_noun pattern (get_status, list_incidents, list_monitors, list_pages), making them predictable and easy to remember.
Four tools are well-scoped for a read-only status page API; each tool covers a distinct resource or view, and no tool feels redundant.
The surface covers listing pages, getting current status, and listing incidents and monitors, which is solid for a status monitoring domain. Minor gaps exist, such as fetching a specific incident or monitor by ID or accessing historical uptime data beyond the current month.
The current status of a page: headline state, monitors, open incidents, planned maintenance, and the month against the uptime target.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The page id, from list_pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses what the response contains, and 'current status' implies a read operation, but it says nothing about whether the call is side-effect-free, what permissions are required, or whether data is live or cached. Partial disclosure only.
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?
One sentence, front-loaded with the core purpose ('the current status of a page') followed by a compact enumeration of the returned facets. Nothing is redundant and everything earns its place.
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?
There is no output schema, so the description must describe return content, and it does so thoroughly by naming all five facets of the status. It is nearly complete for a simple one-parameter read tool, with only behavioral details (auth, read-only guarantees) left unstated.
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?
There is a single parameter and schema coverage is 100%; the schema already documents pageId and its origin ('from list_pages'). The description adds no parameter-level detail, so the baseline of 3 applies.
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 a specific resource (a page's current status) and enumerates exactly what that status comprises: headline state, monitors, open incidents, planned maintenance, and month-vs-uptime-target. This distinguishes it implicitly from the list_* siblings, which enumerate entities rather than aggregate a page's status, though no sibling is named explicitly.
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?
There is no when-to-use or when-not-to-use guidance, no prerequisites, and no reference to the sibling tools. The agent must infer usage entirely from the noun phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Incidents and maintenance on a page, newest first, with every update.
| Name | Required | Description | Default |
|---|---|---|---|
| open | No | Only what is still open. | |
| pageId | Yes | The page id, from list_pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It does disclose ordering (newest first) and that updates are included, which is genuinely useful, but it says nothing about pagination, permissions, result volume, or what an 'update' entry looks like for a read 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?
One short, front-loaded sentence with no padding. It earns its length, though the trailing 'with every update' phrase costs more in ambiguity than it returns in information.
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?
With no annotations and no output schema, the description is the only carrier of behavioral context, and it is too thin for a list tool: no pagination hints, no auth requirements, and the meaning of 'every update' is left undefined. An agent cannot fully predict what it will get back.
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 description coverage is 100%, and the two parameters are documented in the schema itself (including the cross-reference to list_pages for pageId). The description adds no syntax or semantics beyond what the schema already states, so the baseline of 3 applies.
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 names the resource (incidents and maintenance), the scope (on a page) and the ordering (newest first), so the agent can infer a list operation. But 'with every update' is ambiguous jargon, and nothing distinguishes it from siblings like list_monitors or get_status. Purpose is identifiable but not crisp.
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 when-to-use guidance, no alternatives, no exclusions. The description never says when incidents are the right thing versus get_status or list_monitors, leaving the agent to infer selection from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The monitors on a page with their type, target, state and last result.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The page id, from list_pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the returned monitor fields (type, target, state, last result), which is useful since there is no output schema, but it does not mention pagination, ordering, permissions, or error behavior for this read operation.
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 compact sentence with no redundant or filler text, and the resource and returned fields are front-loaded.
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 simple one-parameter list tool, it covers the resource, scope, and returned fields. However, with no annotations and no output schema, it still leaves out practical details such as pagination and when the tool should be chosen over siblings.
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 100% description coverage and explains that pageId is the page id from list_pages. The description's 'on a page' reinforces that parameter but adds no new syntax, format, or source details beyond the schema.
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 identifies the resource (monitors), the scope (on a page), and the returned fields, so an agent can tell it is a monitor-listing tool. It does not explicitly differentiate itself from siblings like list_incidents or get_status, and it omits an explicit verb, but the purpose is clear.
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?
There is no guidance about when to use this tool versus the sibling tools, nor any prerequisites or exclusions. The required pageId comes from list_pages only in the schema, not in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every status page this key reaches, with ids and addresses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the auth scope ('this key reaches') and the return content ('ids and addresses'). It does not state that this is a read-only, non-destructive operation, nor whether results are paginated or ordered, leaving gaps for an unannotated 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?
A single compact sentence with the resource and scope front-loaded and return fields trailing. Nothing is wasted, though the telegraphic 'with ids and addresses' phrasing is slightly terse for a standalone description.
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 zero-parameter list tool with no output schema, the description supplies the essentials: what is listed, the scoping, and the key fields returned. Missing pagination/ordering details are minor against this simplicity.
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 tool takes zero parameters, so there is nothing for the schema to describe and nothing the description needs to compensate for. Baseline 4 applies.
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 names the resource (status pages) and the scope ('this key reaches'), which distinguishes it from siblings like list_incidents and list_monitors that deal with other resources. The verb is only implied by the tool name, but the intent is unambiguous.
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?
There is no statement of when to use this tool versus alternatives, nor any prerequisite or exclusion. The 'this key reaches' clause hints at auth scoping but stops short of telling the agent anything actionable about selection.
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.
get_statuslist_incidentslist_monitorslist_pages
Add one secure layer between your agents and this server.