hetrixmcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action, with clear separation between list/get/update/create/delete operations. Even similar-looking tools like list_blacklists and list_blacklist_monitors are differentiated by their descriptions (RBL definitions vs monitor instances). No two tools perform the same function.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case. Verbs (list, get, update, create, delete, add, remove) clearly indicate the operation, and nouns precisely denote the resource. There are no mixed conventions or ambiguous names.
Tool Count4/5
At 20 tools, the server is slightly above the typical 3-15 well-scoped range but still reasonable given the breadth of HetrixTools' monitoring domains (uptime, blacklist, status pages, agents, maintenance, etc.). Each tool serves a distinct purpose and the count is not overwhelming.
Completeness2/5
The server is heavily read-focused, with no create/update/delete operations for the core resources (uptime monitors and blacklist monitors). While scheduled maintenance and server agents have some write support, the missing CRUD for monitors and status pages leaves significant gaps for management workflows.
Average 3.7/5 across 20 of 20 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation but doesn't disclose error behavior (e.g., what happens if agent_id doesn't exist), permission requirements, or any side effects. The minimal statement offers only basic transparency and no additional behavioral context.
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 immediately states the purpose. It is front-loaded and contains no filler or redundant information, making it an example of efficient, structured communication.
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 get-by-ID tool with an output schema and one required parameter, the description is minimally adequate. It doesn't explain when to use it, error cases, or any nuances, but given the low complexity, the lack of such detail is a moderate gap rather than a severe one.
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% (the sole parameter 'agent_id' is described as 'Server agent ID'). The tool description adds no extra meaning beyond implying that the ID identifies the specific agent to retrieve. Since the schema already captures the parameter semantics, this is adequate but not enhanced.
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 tool's function: 'Get information for a specific server agent.' It uses a specific verb ('Get') and resource ('server agent'), and the word 'specific' distinguishes it from list-type operations among sibling tools. However, it doesn't further elaborate on what 'information' entails or how it differs from potential list/get-all alternatives.
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 usage guidance is provided. The description doesn't mention when to use this tool versus alternatives, such as listing agents or updating/deleting them. It also doesn't specify any preconditions (e.g., agent must exist). This is a clear absence of guidance.
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 adds the detail that it 'Sends a POST request,' but does not explain whether the update is a partial merge or full replacement, what happens to missing keys, permission requirements, or any side effects beyond the HTTP call. For a mutation tool, key behavioral context is missing.
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 concise and front-loaded with the primary purpose in the first sentence. The second sentence, while adding a minor detail about the HTTP method, is not essential and could be omitted without losing core meaning. Overall, it is efficiently worded with no fluff.
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 two-parameter update tool, the description covers the basic purpose, and the output schema likely documents return values. However, it lacks important operational context such as whether settings are merged or replaced, which is critical for an update operation. The presence of an output schema mitigates but does not fully compensate for this 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?
Schema description coverage is 100%, so both parameters (agent_id and settings) are already documented. The description merely restates that settings is a 'dict,' which aligns with the schema's object type, adding no new meaning. Baseline of 3 for high schema coverage 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 'Update a server agent's configuration,' combining a specific verb (Update) with a specific resource (server agent's configuration), which distinguishes it from sibling tools like get_server_agent and delete_server_agent. The purpose is immediately unambiguous.
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 explicit guidance on when to use this tool versus alternatives. It does not mention related tools such as get_server_agent, delete_server_agent, or update_warning_policies, nor any prerequisites or use cases. Usage is only implied by the verb 'update,' but no exclusion or alternative scenarios are described.
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 states the action 'Delete' without explaining side effects, permissions, idempotency, or error behavior, offering minimal 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, concise sentence that front-loads the verb and resource. It contains no unnecessary words or repetition, making it highly efficient.
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?
Output schema is present, so return values are covered. However, the description lacks usage context and behavioral details expected for a delete tool without annotations, making it minimally viable 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 schema has 100% coverage with a clear parameter description ('Server agent ID to delete'). The tool description adds no additional meaning beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the delete action on the server agent resource and notes deletion by ID, distinguishing it from sibling tools like get_server_agent and update_server_agent.
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, nor are prerequisites or consequences mentioned. Given the sibling tools, this lack of context leaves the agent without direction.
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 fully disclose behavior. It mentions sending a PUT request, which hints at replacement semantics, but does not clarify whether all policies are replaced, required permissions, or side effects. This is insufficient 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?
Two short, direct sentences with no fluff. The first states the purpose; the second adds a relevant behavioral detail about the HTTP method. Every word earns its place.
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 has low complexity (2 simple params, output schema exists), so the description is nearly sufficient. However, as a mutation tool with no annotations and no usage guidance, it lacks critical context about when and how to use it appropriately.
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 provides 100% parameter coverage, documenting both monitor_id and policies. The description adds no meaning beyond restating 'policies array,' 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates warning policies for an uptime monitor, using a specific verb and resource. This distinguishes it from read-only siblings like list_warning_policies.
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, prerequisites, or alternatives. The description only states the action and HTTP method, leaving the agent to infer the appropriate context.
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 carries the full burden of behavioral disclosure. It does disclose the response structure (fail_log array fields and meta pagination), which is useful. However, it does not explicitly state that the operation is read-only, or describe potential errors, validation, or side effects. The description adds some value but lacks comprehensive behavioral context.
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 two concise sentences, front-loaded with the main purpose and immediately followed by the return format. Every sentence earns its place, with no filler or redundancy.
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 read-oriented tool with a clear output schema and fully documented parameters, the description is complete enough. It captures the core functionality and key return values. The only gaps are usage guidelines and explicit safety behavior, which are captured in other dimensions.
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 all four parameters with 100% coverage, so the baseline is 3. The description does not add additional semantic meaning beyond the schema; it merely reiterates that the tool targets a specific monitoring location, which is already implied by the 'location' parameter description.
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 states a specific verb ('Get') and resource ('fail log for a specific monitoring location of an uptime monitor'), which clearly identifies the tool's function. It does not explicitly contrast with sibling tools, but the specificity of 'specific monitoring location' inherently distinguishes it from broader reporting tools like get_uptime_report or list_downtimes.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or when not to use it. The only contextual hint is 'specific monitoring location,' but no comparison to related tools is provided.
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 carries the full burden. It implies a read-only operation via 'list' but adds no additional behavioral context such as permissions, rate limits, or edge cases. It offers minimal value beyond the name and schema.
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 with no redundant words. It front-loads the verb and resource, making it easy to parse quickly.
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 simple one-parameter tool with an output schema, the description is adequate. It explains the purpose and scope. However, it omits any potential limitations or caveats, though none are apparent, making it nearly 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 input schema already describes the only parameter (monitor_id as 'Uptime monitor ID') at 100% coverage. The description adds no further meaning, so the baseline of 3 applies.
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) and the resource (warning policies) scoped to an uptime monitor. It distinguishes from sibling tools like update_warning_policies (update) and list_uptime_monitors (list monitors).
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 explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The usage is only implied by the name and verb.
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?
The description mentions 'Sends a POST request', which is a useful technical detail, but it fails to disclose important behavioral traits such as idempotency, how duplicates are handled, whether existing monitor lists are replaced or appended, or any authorization requirements. Since no annotations are provided, the description carries the full burden of behavioral disclosure and falls short.
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 extremely concise, consisting of two sentences with the core action front-loaded in the first sentence. No unnecessary detail or filler is present.
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 simple tool with only two parameters and an existing output schema, the description covers the essential action and HTTP method. However, it lacks details about preconditions (e.g., status page existence, valid monitor IDs) or error behavior, which would be valuable in a complete context.
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 fully describes both parameters (status_page_id and monitor_ids). The description merely restates these parameters without adding any extra meaning, such as allowed formats, relationships, or constraints beyond the schema.
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 'Add monitors to a status page' with a specific verb and resource, making the tool's purpose immediately obvious. It also distinguishes itself from the sibling 'remove_monitors_from_status_page' by focusing on the add action.
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?
No explicit guidance is given about when to use this tool versus alternatives like 'list_status_pages' or 'remove_monitors_from_status_page'. The usage is implied by the name and description, but there are no explicit when-to-use or when-not-to-use instructions.
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 full burden. It does reveal that the tool 'Sends a POST request' and lists the payload fields, which adds concrete behavioral context beyond just 'create'. However, it does not disclose potential side effects, permission requirements, or error conditions. This is moderate transparency, slightly better than a bare description but not comprehensive.
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 concise at two sentences, with the primary purpose front-loaded in the first sentence. The second sentence adds relevant technical detail (HTTP method and fields) without redundancy. Every sentence serves a clear purpose, making it well-structured and easily scannable.
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 moderate complexity (5 params, 3 required, output schema present) and excellent schema coverage, the description is largely complete. It covers the core purpose and input fields, while the output schema handles return values. It does not, however, mention any operational constraints (e.g., date validation), but the overall context is sufficient for an agent to use the tool correctly in most cases.
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% coverage, so the baseline is 3. The description lists the main parameters (name, dates, monitor IDs, description) but adds no new meaning beyond what the schema already provides. It does not clarify formats, constraints, or examples beyond the schema descriptions, so it contributes little additional parameter-level 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 clearly states the tool's function: 'Create a scheduled maintenance window.' This is a specific verb+resource combination that directly distinguishes it from sibling tools like delete_scheduled_maintenance and list_scheduled_maintenance. The action is unambiguous and immediately understandable.
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 does not provide guidance on when to use this tool versus alternatives. It states the action but gives no prerequisites, no explicit exclusions, and no mention of when not to use it. Unlike the high-calibration example that explicitly names an alternative, this description relies solely on the verb 'create' to imply usage, which falls short of clear usage guidance.
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 carries the full burden. It discloses the deletion action but omits any information about irreversibility, side effects on associated data, or whether the operation is a hard delete. For a destructive tool, this is a significant transparency gap.
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 immediately states the action and target. It contains no filler or redundant information, achieving maximum conciseness while remaining clear.
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 (one parameter, clear output schema), the description is largely complete. It does not need to explain return values due to the output schema. However, a brief mention of the ID's origin (e.g., from list_scheduled_maintenance) or irreversible nature would enhance completeness, so it falls just short of a 5.
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 covers 100% of the parameter, and the maintenance_id property already has a clear description ('Scheduled maintenance ID to delete'). The tool description adds no extra semantic value beyond the schema, so 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 uses a specific verb ('Delete') and resource ('scheduled maintenance window') combined with an ID reference, making the tool's function unambiguous. It also clearly distinguishes from sibling tools like create_scheduled_maintenance and list_scheduled_maintenance.
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 intended usage is implied by the tool name and description, but there is no explicit guidance on when to use it versus alternatives, nor any mention of prerequisites or exclusions. It only states the action without context such as 'use this to remove an existing window' or 'not for editing.'
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 partially carries the behavioral burden by detailing the return structure (monitors array, meta object with pagination). However, it does not explicitly state that this is a read-only operation or describe any potential side effects, auth requirements, or rate limits. The 'list' verb implies safety, but the disclosure is not thorough.
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 extremely concise: two sentences that lead with the core purpose and then summarize the return payload. Every sentence adds value, and there is no redundant or filler content.
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 that an output schema exists and the description includes a compact summary of returned fields, the tool is well-documented for a list operation. The only minor gap is the absence of details about default sorting or error behavior, but these are not critical for a straightforward paginated list endpoint.
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% coverage with descriptions for all 11 parameters. The description adds only a generic mention of 'optional filters and pagination', which does not meaningfully enhance the schema's already clear parameter semantics. The baseline of 3 applies because the schema does the heavy lifting.
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') and the specific resource ('blacklist monitors'), distinguishing it from sibling tools like list_blacklists (which lists blacklists themselves) and get_blacklist_report.
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 does not provide any guidance on when to use this tool versus alternatives (e.g., list_blacklists or get_blacklist_report). It simply describes the action with no exclusions or context that would help an agent choose it.
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 carries the full burden. It discloses that a DELETE request is sent, which implies mutation, but it does not state whether the operation is irreversible, whether it requires authorization, or what side effects occur (e.g., affecting status page availability). This is insufficient for full 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 two sentences with no redundant or filler content. It front-loads the primary action and then provides a concise technical note about the HTTP method.
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 simple two-parameter tool with an output schema and high schema coverage, the description provides enough context to understand the operation. The gap is minor: it lacks guidance on when to use this versus the sibling add tool, but the core action is fully covered.
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 each parameter already well-described. The tool description merely restates the parameter names without adding new semantic insight, so 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 clearly states the tool's function: removing monitors from a status page, with a specific verb and resource. The sibling tool add_monitors_to_status_page makes the opposite operation obvious, and the description's mention of the DELETE request adds technical precision.
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 implied usage is clear: use this tool when you need to remove monitors from a status page. However, there is no explicit guidance on when not to use it, nor mention of alternatives beyond the name itself. The description does not discuss prerequisites or distinctions from related tools.
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 full burden of behavioral disclosure. It does disclose the return format (two arrays: ipv4 and domains, with fields including optional/ignored flags), which is useful. However, it does not mention any other behavioral aspects like whether the list includes disabled RBLs, pagination, or error conditions. It is adequate but not comprehensive.
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 two sentences, front-loaded with the main purpose in the first sentence and output details in the second. There is no redundant information, and every word serves a purpose. It is a model of conciseness.
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) and the presence of an output schema, the description is nearly complete. It provides enough context about the return structure (ipv4 and domains arrays) to give the agent a clear idea of what to expect. It lacks only deeper behavioral details, but the output schema likely covers the exact shape. Overall, it is sufficiently complete for a straightforward list operation.
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%. Per the guidelines, a parameterless tool receives a baseline of 4. The description does not need to explain parameters, and it doesn't. It adds value by describing the output, which is more relevant than parameter semantics here.
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 purpose: 'Get the list of blacklists (RBLs) checked by the HetrixTools platform.' It specifies the resource (HetzrixTools blacklists), the action (get/list), and the scope (checked by platform). The additional detail about returning ipv4 and domains arrays further distinguishes it from sibling tools like list_blacklist_monitors, making the purpose unambiguous.
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?
There is no explicit guidance on when to use this tool versus alternatives. It does not mention list_blacklist_monitors, get_blacklist_report, or any other sibling as a contrast, nor does it mention any prerequisites or contextual triggers. The usage is only implied by the tool name and self-explanatory purpose.
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 discloses that the tool lists account-level contact lists and enumerates the fields returned (id, name, default flag, notification channels). However, it does not explicitly state that the operation is read-only, mention pagination behavior, or note any authentication/authorization requirements. The 'list' wording implies non-mutating behavior, but this is not explicitly reinforced.
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 concise, consisting of two sentences that immediately state the primary function and then detail the output fields. It is front-loaded with the core action and provides no unnecessary information.
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?
This is a simple list tool with only pagination parameters and an output schema. The description sufficiently covers the tool's scope and the content of the returned data. Since an output schema exists, no further return format explanation is needed. Minor omissions like pagination details are already handled by the schema, so the description is mostly complete for this low-complexity 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 has 100% coverage for the two parameters (page and per_page), each with clear descriptions and defaults. The tool description adds no additional parameter semantics beyond what the schema already provides, so 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 clearly states the tool's purpose: 'List contact lists configured on the account.' It uses a specific verb ('list') and identifies the resource ('contact lists'), which distinguishes it from sibling tools that operate on resources like monitors, blacklists, or scheduled maintenance. The scope ('configured on the account') adds precision.
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 when to use the tool (when you need to list contact lists) but does not provide explicit guidance on when not to use it or mention alternatives. There are no sibling tools that overlap with contact lists, so context is clear, but no direct exclusions or alternative references are given.
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 is the sole source of behavioral context. It discloses the operation is a read ('List') and the scope ('all... on the account'), but does not mention pagination, ordering, or response details. This is minimal but not misleading.
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?
A single sentence with no redundant wording. It states exactly what the tool does without filler, which is appropriate for a parameterless list tool.
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?
Given the tool's simplicity (no parameters, output schema exists), the description covers the full behavior. It describes the action, the object, and the scope, which is complete for a list-all operation.
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 baseline is 4. The description adds no parameter-specific detail, but none is needed since the schema is empty and coverage is 100%.
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 ('status pages'), with a clear scope ('configured on the account'). It implicitly distinguishes from sibling list tools by naming a unique resource.
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, no exclusions, and no prerequisites. The use case is implied by the name and description but never explicitly stated.
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 full burden. It discloses the return shape (a monitors array with detailed fields) but does not explicitly state that the operation is read-only, lacks side effects, or requires any special permissions. The 'List' verb implies a safe read but this is not stated.
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 two sentences: the first states the action and general behavior, the second enumerates the return fields. It is front-loaded with the core purpose and avoids fluff. The second sentence is a long list but is still informative and earns its place, though it may overlap with the output schema.
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?
With 11 optional parameters, 100% schema coverage, and an output schema available, the description is sufficient for an agent to understand the tool's role. It lacks only explicit guidance on when to choose this over related tools and any edge-case behaviors like result limits, but overall it is complete for a list operation.
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%, so the baseline is 3. The description only mentions 'optional filters and pagination' without adding meaning beyond the schema's parameter descriptions. It does not explain parameter formats, dependencies, or defaults beyond what the schema already provides.
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 'List' with the resource 'uptime monitors' and explicitly mentions optional filters and pagination. It clearly distinguishes from sibling list tools (list_warning_policies, list_downtimes, etc.) by focusing on uptime monitors.
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: it lists monitors with optional filters/pagination. However, it does not explicitly mention when to use this tool over alternatives (e.g., get_uptime_report for summaries) or any exclusion criteria.
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 what it returns but does not explicitly mention that it is a read-only operation, whether any authentication is needed, or if results are real-time. The verb 'Get' implies non-mutating, but this is not explicit, leaving a transparency gap.
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 two sentences, front-loaded with the primary purpose and followed by a concise list of return categories. Every sentence adds value with no redundancy or filler.
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 zero-parameter tool with an output schema, the description adequately covers its purpose and return scope. It lists all relevant usage/limit categories. It does not address authentication or error conditions, but given the simplicity and available output schema, this is sufficient.
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% (trivially). Per the rubric, a baseline of 4 applies; the description does not need to explain parameter semantics beyond what the schema shows.
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 'Get current HetrixTools account usage and limits', which is a specific verb+resource combination. It also lists the categories of usage/limits returned (uptime monitors, blacklist monitors, etc.), distinguishing it from sibling tools that list individual resources or reports.
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 makes the use case evident: it is for retrieving account-level usage and limits, not for listing specific entities like monitors or blacklists. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.
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 carry the safety burden. It honestly describes the return structure including fields like id, http_code, started_at, ended_at, and pagination meta, but does not mention side effects, auth requirements, or potential errors. For a read-only listing operation, this is adequate but not explicit about being non-destructive.
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?
Two concise sentences; the first states the primary function, the second summarizes the return payload. No filler or redundant information.
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 description covers the core function, the required monitor scope, and the output shape including pagination. While it doesn't discuss usage alternatives or error conditions, the presence of an output schema and the straightforward nature of the tool make this sufficient. It could be more complete with a note on default pagination or time range, but given the output schema, it's not necessary.
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 provides 100% coverage with descriptions for all parameters. The description adds no new parameter semantics beyond restating that downtimes are for a specific monitor (which maps to monitor_id). Baseline 3 applies.
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 'List downtimes for a specific uptime monitor' - a specific verb, resource, and scope. It distinguishes from sibling tools like list_uptime_monitors (which lists monitors) and get_uptime_report (which provides a report), by focusing on downtime events for a single monitor.
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?
It implies when to use: when needing downtime records for a particular monitor, as opposed to list_uptime_monitors that lists monitors themselves. However, it does not explicitly exclude alternatives or mention sibling tools, so it's clear context but no explicit exclusions.
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 carries the full burden. 'List all' clearly indicates a read-only operation, but it does not mention potential pagination, rate limits, or authentication requirements. The simplicity of the operation partially compensates, but there is no extra behavioral context beyond the verb.
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?
A single, front-loaded sentence that delivers the essential information without any wasted words. Perfectly concise for the tool's simplicity.
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 parameterless list tool with an output schema present, the description is complete. It states exactly what the tool returns (all scheduled maintenance windows), and the output schema covers the return value details. No additional context is needed.
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 already provides full coverage. The description does not need to elaborate on parameters; the baseline of 4 applies since there are no parameter semantics to clarify.
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 a clear resource ('all scheduled maintenance windows'). It distinctly identifies this tool from siblings like create_scheduled_maintenance and delete_scheduled_maintenance, and from list_downtimes which likely targets unplanned incidents.
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?
No explicit guidance on when to use this tool versus alternatives. The context implies it is the dedicated listing tool for scheduled maintenance, but there is no stated exclusion or comparison to sibling tools. This falls under 'implied usage'.
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?
No annotations are provided, so the description correctly takes on the burden of explaining output. It discloses the exact fields returned, including the `listed` array and the monitor identifiers. It doesn't discuss errors or side effects, but 'Get' implies a read-only, non-destructive operation, and the output disclosure adds meaningful context beyond the operation name.
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?
Two sentences: the first states the purpose, the second lists return values. No wasted words, and information is front-loaded. Every sentence earns its place.
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 (2 params, 1 required) and an output schema exists (context signal). The description covers the essential semantic details, including what the `listed` array represents. It doesn't discuss edge cases like invalid identifiers, but given the simplicity and output schema, it is sufficiently 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%: both `identifier` and `date` are fully described with formats and defaults. The description adds no additional parameter semantics, so it relies entirely on the schema. This meets the baseline for high coverage but does not exceed it.
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?
Description clearly states the action: 'Get the blacklist report for a specific monitor' with a specific resource (blacklist report) and scope (specific monitor). It distinguishes from sibling list tools like list_blacklist_monitors or list_blacklists, which are for collections.
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 phrase 'for a specific monitor' implies this is for retrieving a single monitor's report, as opposed to listing monitors or blacklists. However, it does not explicitly mention alternative tools when the user wants multiple reports, but given the sibling names, the use case is clear enough.
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 full burden. It discloses the return structure (timezone, per-day data, summary, history) and implies a read-only operation via 'Get'. It doesn't mention auth or rate limits, but for a report-fetching tool, this is reasonably 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?
Two sentences: the first states the core action and scope, the second enumerates the key return fields. No filler or repetition. Every sentence earns its place.
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 has an output schema, the description doesn't need to explain return values, but it does, which is beneficial. It lacks any note about the relationship between 'days' and 'month' (possibly mutually exclusive), which is a minor gap but not fatal for an agent.
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% parameter coverage with clear descriptions (days, month, timezone, monitor_id, hourly_stats). The tool description adds no extra parameter-level detail beyond mentioning optional hourly_stats in the output, which is redundant. Baseline 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 opens with 'Get the uptime report for a specific monitor' — a clear verb+resource+scope. It distinguishes this from sibling tools like list_uptime_monitors and list_downtimes by focusing on a per-monitor report.
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?
It clearly targets a specific monitor's uptime report, implying when to use it, but it does not explicitly mention alternatives or exclusions. For example, it doesn't say 'for listing monitors, use list_uptime_monitors.' Still, the scope is clear enough for an agent to select it appropriately.
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:

[![hetrixmcp MCP server](https://glama.ai/mcp/servers/khrns-r/hetrixmcp/badges/card.svg)](https://glama.ai/mcp/servers/khrns-r/hetrixmcp)

Score Badge

Copy to your README.md:

[![hetrixmcp MCP server](https://glama.ai/mcp/servers/khrns-r/hetrixmcp/badges/score.svg)](https://glama.ai/mcp/servers/khrns-r/hetrixmcp)

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/khrns-r/hetrixmcp'

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