@mnicole-dev/updown-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool clearly targets a distinct resource and action: checks, nodes, recipients, and status pages each have their own list/get/create/update/delete where applicable, with no overlapping purposes. The specialized check metrics and downtimes tools are unambiguous subsets of check data.
Naming Consistency5/5
All tool names follow a consistent kebab-case verb-noun pattern (e.g., list-checks, create-status-page). The pattern is predictable across all resources, with compound names like get-check-downtimes extending the same convention.
Tool Count5/5
15 tools is within the well-scoped 3-15 range for a domain-specific server. Each tool maps to a real operation on the Updown.io API, and the count feels right for covering the main resources without unnecessary bloat.
Completeness4/5
Checks and status pages have full CRUD coverage, plus additional check-specific operations. Recipients lack an update operation, but since recipients are likely simple contact addresses, create/delete/list may be sufficient. Overall the surface covers the core domain well with only minor gaps.
Average 3.4/5 across 15 of 15 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the tool's name. With no annotations provided, it fails to disclose whether a token is required, whether updates are partial, or any side effects, making it essentially a tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only six words. However, it is under-specified for a mutation tool with 6 parameters, lacking necessary context; it's concise but not appropriately informative, so a middle score is warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, mutation, no output schema), the one-sentence description is insufficient. It doesn't mention return values, required fields, or the implications of updating a status page, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all 6 parameters with individual descriptions, covering 100% of the schema. The description itself adds no parameter semantics, but the schema does the heavy lifting, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('existing status page'), which distinguishes it from create-status-page and delete-status-page. However, it lacks details on what fields can be updated or any scope, preventing a higher score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The word 'existing' implies it's not for creating pages, but it doesn't explicitly mention alternatives like create-status-page or refer to any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It merely states the creation of a public status page but omits details like authentication, response format, side effects, and the fact that private pages are also possible via the visibility parameter, which contradicts the 'public' claim.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant content, earning credit for brevity. However, it is under-specified for a tool with five parameters and several nuances, so it does not achieve the higher score that complete, efficient descriptions get.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, and no output schema, so the description needs to explain the creation process and return behavior. It does not mention what the API returns, whether checks must already exist, or the implications of different visibility settings, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters have descriptions in the schema, so the baseline of 3 applies. The description adds no additional parameter-level context, but the schema adequately covers each field's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (create) and the resource (status page), which is sufficient to distinguish from sibling tools like update-status-page and delete-status-page. However, the qualifier 'public' may mislead, since the schema includes a 'visibility' parameter supporting private pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool instead of alternatives like update-status-page or delete-status-page. It also fails to mention prerequisites, such as the need for existing checks to attach, or how visibility works.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Create a new monitoring check' and does not mention side effects, validation, defaults, permissions, or what happens upon creation. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It front-loads the core purpose immediately. While minimal, it is not verbose or padded, earning a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters and no output schema, the description is bare. It does not explain the return value, required fields, or how parameters interact. The schema documents parameters, but the overall creation behavior is inadequately described, leaving the agent with many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 13 parameters, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, but it does not need to since the schema fully documents each property.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('monitoring check'), and the word 'new' distinguishes it from update operations. It is distinct from sibling tools like create-recipient and create-status-page, though it does not elaborate on what a monitoring check entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or when to prefer update-check instead. The single sentence offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Delete an alert recipient' without mentioning permanence, side effects, or required permissions, leaving the agent uninformed about destructive consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. While minimal, it is appropriately concise for a simple delete operation, though it could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is too sparse. It fails to convey whether the delete is permanent, whether it cascades, or what happens if the recipient is in use. Given the simplicity of the tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter 'id' with its type and description, so the tool description adds no additional semantic value. Baseline of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as 'alert recipient,' clearly distinguishing it from sibling tools like list-recipients and create-recipient. However, it doesn't elaborate on scope or conditions, so it's clear but not fully descriptive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, alternatives, or exclusions. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'Update' without revealing whether updates are partial (PATCH-like) or full replacements, whether the operation is idempotent, what happens on invalid tokens, or what response format to expect. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's purpose. It wastes no words and is appropriately sized for a tool with a self-explanatory name and rich schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex mutation tool with 14 parameters, no output schema, and no annotations. The description provides almost no contextual information beyond the basic action, leaving the agent without guidance on return values, error handling, or update semantics. It is far from complete for such a feature-rich tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all 14 parameters, achieving 100% schema description coverage. The tool description itself adds no parameter-specific information, but the schema already handles that responsibility. A baseline of 3 is appropriate since the schema covers parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Update') and resource ('an existing monitoring check'), distinguishing it from create-check and delete-check through the word 'existing'. It is specific and unambiguous despite its brevity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create-check or delete-check. It lacks context on prerequisites, such as requiring an existing check token, or scenarios that warrant update over recreation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavior. It only states the action 'create' without mentioning side effects, idempotency, validation, or what happens on duplicate values. The lack of any return value description or error scenarios further reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and free of unnecessary words. It is appropriately concise for a simple create operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter create tool, the description is adequate: it states the purpose and the schema covers inputs. However, there are gaps such as lack of output/return information and no mention of uniqueness constraints or how the recipient will be used. This is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptive text (type, value, name, selected), so the baseline is 3. The description adds no extra parameter meaning, but the schema descriptions are sufficient for an agent to understand the expected inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (alert recipient), distinguishing it from sibling tools like list-recipients and delete-recipient. It is concise and specific, though it lacks additional context about what an alert recipient is or how it relates to the broader alerting system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and context. This is a minimal but acceptable level of guidance for a simple CRUD operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It states the delete action but does not mention whether deletion is permanent, whether there are side effects, or any authorization requirements beyond the token parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the verb and avoids any redundant information. It earns a high score for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description plus schema provide the basic action. However, the lack of behavioral context (e.g., permanence, cascading effects) leaves it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the token parameter with a description ('Status page token'), and the tool description does not add extra meaning. This matches the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'status page', clearly distinguishing it from sibling tools like create-status-page, update-status-page, and list-status-pages. It is unambiguous and exactly describes the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as deactivating a status page via update-status-page. The description only states the action without any contextual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates a read operation ('get') but fails to mention pagination behavior (despite the 'page' parameter), response structure, or any additional context such as ordering or filtering. The description is too minimal to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's purpose. It is front-loaded with the main action and resource, containing no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (read history with two params), and the schema covers parameter meaning. However, the absence of an output schema and any description of what the downtime history includes (e.g., start/end times, duration) leaves some gaps. The description is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'page' and 'token' already described in the input schema. The tool description adds no extra parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets downtime history for a monitoring check, using a specific verb ('get') and resource ('downtime history'). It effectively distinguishes itself from sibling tools like get-check (which retrieves check details) and get-check-metrics (which retrieves metrics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states what the tool does without any context on prerequisites, exclusions, or comparisons to sibling tools. Usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does not disclose any behavioral traits beyond the literal action, such as whether deletion is irreversible, whether it cascades to associated data, or whether special permissions are required. The description is minimal and leaves these important aspects unmentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no wasted words. It conveys the essential purpose immediately and is appropriately concise for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no output schema), the description is minimally sufficient but lacks important context such as consequences of deletion or any special behaviors. It could be more complete by noting that the deletion is destructive and possibly irreversible, making it incomplete for an unannotated tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'token' parameter as 'Check token', providing 100% schema coverage. The description itself adds no additional meaning about parameters, but since the schema covers the single parameter adequately, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a monitoring check' clearly states a specific action (delete) on a specific resource (monitoring check). It effectively distinguishes this tool from sibling tools like list-checks, get-check, create-check, and update-check by focusing on the deletion operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (use when you want to delete a monitoring check) but provides no explicit guidance on when to use it versus alternatives, nor does it mention any prerequisites or when not to use it. The verb 'delete' gives a clear context, but no explicit exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It states the operation is read-only ('Get details') and optionally includes metrics, but does not describe response format, error handling, or the effect of the metrics parameter. The behavior is safe and simple, but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action and resource. There is no wasted wording, and it clearly communicates the optional metrics flag.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and no output schema, but the description does not specify what 'details' includes or clarify how the metrics parameter affects the response. It is adequate for basic understanding but could benefit from a note on return value structure or distinction from get-check-metrics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'token' and 'metrics' described in the input schema. The description adds little beyond the schema, reinforcing the optional metrics behavior but not providing additional semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get details') and identifies the resource ('a single monitoring check'), clearly distinguishing from list-checks. However, it does not explicitly distinguish from sibling get-check-metrics or get-check-downtimes, though the 'optionally including metrics' clause partially addresses that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'single' implies this is for one check as opposed to list-checks, but no explicit when-to-use or alternative guidance is provided. It does not mention alternatives like get-check-metrics for focused metric retrieval, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Get performance metrics', which indicates a read operation, but omits details about required permissions, response format, or potential side effects. The phrase 'over a time range' also introduces a constraint not enforced by the schema (from/to are optional).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the key action and resource. Every word is necessary, and it avoids filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature and rich schema, the description is adequate but incomplete: it does not mention response format, that from/to are optional, or how to use the group parameter. Annotations and output schema are absent, so more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all parameters, so the baseline is 3. The tool description adds no param-specific meaning beyond saying 'over a time range', which only loosely maps to from/to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with the resource 'performance metrics for a monitoring check' and qualifies with 'over a time range', clearly distinguishing it from sibling tools like get-check and get-check-downtimes. It precisely states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving metrics over a time range, but does not explicitly state when to use this tool over alternatives or any exclusions. It provides context but no explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It states a list operation scoped to the account, implying a safe read, but does not disclose pagination, ordering, or the structure of returned recipient objects. The 'all' wording suggests no pagination, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'List' and provides the necessary scope. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no input parameters and no output schema. The description sufficiently explains the tool's purpose, but it could be slightly more complete by mentioning the return format (e.g., list of recipient objects with contact details). Given the simplicity, the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is trivially 100%. Per the rubric, a 0-parameter tool gets a baseline of 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with the resource 'alert recipients' and scope 'all configured in your Updown.io account'. This clearly distinguishes it from sibling tools like list-checks, create-recipient, and delete-recipient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only operation for viewing recipients, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool mentions are provided, though the resource type differentiates it from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the operation is a read/list, but does not disclose potential pagination, rate limits, or the exact shape of returned data. For a simple list tool this is acceptable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action and resource. No wasted words, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description provides enough context to understand the tool's purpose. It could mention that it returns an array of checks, but 'list all' implies this. Overall, it is adequately complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. Per the baseline, 0 parameters warrant a score of 4. The description adds no parameter details because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all monitoring checks in your Updown.io account' uses a specific verb ('List') and resource ('monitoring checks'), clearly distinguishing it from siblings like get-check (single) or create-check (mutation). The scope 'all' and account context are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to list all checks) but does not explicitly mention alternatives or exclusions. The context is clear, and sibling tool names make it easy to infer when to use get-check for a specific check, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds a useful behavioral nuance by specifying 'public' status pages and limiting to the user's Updown.io account. However, it does not disclose pagination, return format, or any authentication requirements beyond the implicit account scope. For a simple list operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose immediately. Every word contributes to the meaning, with no repetition or filler. It is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is nearly complete. It clearly indicates the tool returns a list of public status pages. The lack of explicit return-type detail (e.g., array of objects) is acceptable for such a straightforward list operation, but the description could have mentioned the read-only nature or the fact that no authentication is needed if the pages are public.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The description adds meaning by defining the implicit filter ('public', 'in your account') that shapes what is returned. Since there are no parameters to explain, the description does not need to provide parameter-level detail, and the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('public status pages'), and the scope ('in your Updown.io account'). It differentiates from sibling tools like list-checks, list-nodes, and list-recipients by naming the exact resource. The verb and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for listing status pages, as opposed to creating, updating, or deleting them. It doesn't explicitly name alternatives or exclusions, but the resource specificity makes the usage context obvious. The absence of explicit comparison to list-checks or other list tools is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'List all' clearly indicates a read-only operation with full scope, and 'global probe locations' adds meaningful context about the response content. No hidden behaviors are likely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. Every word contributes meaning, and there is no unnecessary padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no params and no output schema, the description fully captures the tool's behavior and scope. No additional context is necessary, and the sibling list makes the tool's role clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuously). Per the baseline rule for zero-param tools, no parameter explanation is needed, so the description adds sufficient value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Updown.io monitoring nodes'), and clarifies they are 'global probe locations'. This clearly distinguishes it from sibling tools like list-checks and list-recipients.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies usage (when you need node locations), but there is no explicit guidance contrasting this with alternatives like list-checks. No exclusions or when-not-to-use instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![updown-mcp-server MCP server](https://glama.ai/mcp/servers/mnicole-dev/updown-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/mnicole-dev/updown-mcp-server)

Score Badge

Copy to your README.md:

[![updown-mcp-server MCP server](https://glama.ai/mcp/servers/mnicole-dev/updown-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/mnicole-dev/updown-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mnicole-dev/updown-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server