MCP Prometheus

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, such as get_alerts for fetching alerts and run_check for executing specific checks. However, list_loki_apps, list_loki_environments, and list_loki_hosts are ambiguous without descriptions, potentially causing confusion about their specific functions and differences.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as list_servers, run_promql, and find_logs. All tools use snake_case without any deviations, making the naming predictable and easy to understand.
Tool Count4/5
With 12 tools, the count is well-suited for a Prometheus monitoring server, covering key operations like listing resources and running queries. It's slightly on the higher side but remains reasonable for the domain, though some tools like the Loki-related ones might be redundant or under-specified.
Completeness3/5
The toolset provides good coverage for querying and listing operations in Prometheus, including alerts, checks, and servers. However, there are notable gaps, such as missing tools for creating or managing alerts, configuring checks, or handling Loki data beyond listing, which limits full lifecycle management in the monitoring domain.
Average 2.6/5 across 12 of 12 tools scored. Lowest: 1/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
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
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?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
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?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
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?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
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?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
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 mentions 'Fetch active alerts' and 'Filters (exact-match)', but lacks critical details such as whether this is a read-only operation, potential rate limits, authentication requirements, or what 'active' specifically means (e.g., time-based criteria). This leaves significant gaps for an AI agent.
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 brief and front-loaded with the main purpose, followed by a bullet point for filters. It avoids unnecessary words, but the formatting could be slightly improved for clarity (e.g., separating the filter list more distinctly).
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 tool's moderate complexity (9 parameters, no annotations, but with an output schema), the description is partially complete. It covers the core purpose and some parameters but lacks behavioral details and usage context. The presence of an output schema means return values are documented elsewhere, reducing the burden on the description.
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 description lists six filter parameters (severity, state, alertname, job, server_name, instance) and notes they are 'exact-match', adding semantic context beyond the schema's 0% coverage. However, it omits three other parameters (include_alerts, environment, env_hint) and doesn't explain their purposes, leaving some parameters undocumented.
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 ('Fetch active alerts') and the source ('from Prometheus /api/v1/alerts'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'list_checks' or 'run_promql' that might also relate to monitoring or Prometheus data, which prevents a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_checks' or 'run_promql' for comparison, nor does it specify prerequisites, contexts, or exclusions for usage.
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 full burden. It mentions the source metric and label queried, which adds some context about data sourcing. However, it doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, or what happens if parameters are omitted. The description is minimal and lacks critical operational details.
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 very concise and front-loaded, with the core purpose stated first. Every sentence adds value: the first defines the action, and the second specifies the metric details. There is no wasted text, making it efficient and well-structured.
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 tool's complexity (listing with parameters) and lack of annotations, the description is incomplete. It covers the data source but omits parameter semantics and behavioral context. However, since an output schema exists, the description doesn't need to explain return values. This partial coverage results in a mediocre score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides no information about the two parameters ('environment' and 'env_hint'), their meanings, or how they affect the query. The description only discusses the metric source, leaving parameters entirely undocumented, which is insufficient given the low 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 clearly states the tool's purpose: 'Return process group names from process monitoring metrics.' It specifies the verb ('return') and resource ('process group names'), and mentions the source metric. However, it doesn't explicitly differentiate this from sibling tools like 'list_checks' or 'list_servers', which also list resources.
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 doesn't mention sibling tools or contexts where this is preferred over other listing tools. The only implicit context is 'process monitoring metrics,' but this lacks explicit usage rules or exclusions.
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 full burden. It states it returns checks but doesn't disclose behavioral traits like whether it's read-only, if it requires authentication, rate limits, or pagination. The response format is described, but this is covered by the output schema, so it adds minimal value beyond structured data.
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 appropriately sized and front-loaded, stating the core purpose in the first sentence. The response details are included but are necessary for clarity given the lack of annotations, and every sentence earns its place without waste.
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 tool's simplicity (0 parameters, output schema provided), the description is adequate but has gaps. It explains what is returned, which the output schema covers, but misses behavioral context like safety or usage guidelines, making it minimally viable but not fully complete.
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?
With 0 parameters and 100% schema description coverage, the baseline is high. The description doesn't need to add parameter details, and it doesn't introduce any confusion, so it meets expectations for a parameterless tool.
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 verb ('Return') and resource ('all allowlisted monitoring checks available to the MCP server'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_alerts' or 'run_all_checks', which might have overlapping domains, so it doesn't reach the highest 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on tool names alone, which is insufficient for optimal 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the response format, which adds some value, but fails to cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 front-loaded with the main purpose in the first sentence, followed by a clear breakdown of the response format. Every sentence adds value without redundancy, making it efficient and easy to parse. The structure is logical and concise, with no wasted words.
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 that the tool has 0 parameters, 100% schema coverage, and an output schema exists (implied by the response description), the description is moderately complete. It explains the return values, which compensates for the lack of output schema details. However, without annotations and with no usage guidelines, it falls short of being fully comprehensive for effective tool invocation.
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 0 parameters, and the schema description coverage is 100%, so there is no need for parameter explanation in the description. The baseline score for such cases is 4, as the description appropriately avoids redundant information and focuses on other aspects like the response structure.
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 purpose: 'Return configured Prometheus environments and their base URLs.' It specifies the verb ('Return') and resource ('configured Prometheus environments and their base URLs'), making the function evident. However, it does not explicitly differentiate from sibling tools like 'list_loki_environments', which might cause confusion in usage context.
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 lacks context such as prerequisites, when it should be used over similar tools like 'list_loki_environments' or 'list_servers', and any exclusions or specific scenarios for its application. This absence of usage instructions could lead to incorrect tool selection by an AI agent.
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 of behavioral disclosure. It adds useful context beyond the input schema: it specifies the query timeframe ('last 10 minutes'), the PromQL query pattern ('up{server_name!=""}'), and the return format ('unique targets by (instance, job) with server_name'). However, it lacks details on permissions, rate limits, error handling, or whether this is a read-only operation, which is important for a tool querying monitoring data.
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 well-structured and front-loaded: the first sentence states the purpose, followed by clear sections for 'Inputs' and 'Behavior.' Every sentence earns its place by adding specific, non-redundant information. There is no wasted text, and it's appropriately sized for a tool with two parameters and specific behavior.
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 (2 parameters, no annotations, but with an output schema), the description is mostly complete. It covers purpose, parameters, and behavior, and the output schema likely handles return values. However, it lacks context on error cases, authentication needs, or how it fits with sibling tools, which would enhance completeness for an agent.
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?
Schema description coverage is 0%, so the description must compensate. It explains the two parameters: 'environment' as 'explicit environment key (highest priority)' and 'env_hint' as 'fallback environment hint when environment is not provided.' This clarifies their roles and priority, adding meaningful semantics beyond the bare schema. However, it doesn't specify what values are valid (e.g., example environments) or how they affect the query, preventing a perfect score.
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 purpose: 'List monitored servers detected from recent `up{server_name!=""}` series.' It specifies the verb ('List') and resource ('monitored servers'), and mentions the data source. However, it doesn't explicitly differentiate this from sibling tools like 'list_loki_hosts' or 'list_process_groups', which prevents a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_loki_hosts' or 'list_checks', nor does it specify prerequisites, exclusions, or typical scenarios for selecting this tool over others. The behavioral section describes what the tool does, not when to use it.
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 of behavioral disclosure. It adds useful context about the guardrail requirement and the two execution modes (instant vs. range queries), which helps the agent understand prerequisites and behavioral traits. However, it doesn't cover other important aspects like rate limits, authentication needs, error handling, or what the output looks like (though an output schema exists).
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 and well-structured with clear sections (Guardrail, Modes). Every sentence earns its place by providing essential information without any fluff or repetition. It's front-loaded with the core purpose and efficiently organized.
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 high complexity (18 parameters, 0% schema coverage) but with an output schema present, the description is moderately complete. It covers the core purpose, guardrail, and execution modes, which are crucial. However, with so many undocumented parameters and no annotations, it leaves significant gaps in understanding parameter usage and behavioral context beyond what the output schema provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It only explains two parameters ('approved' and 'instant') out of 18 total parameters. While it provides meaningful context for those two, it leaves 16 parameters completely unexplained, failing to adequately compensate for the poor 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 clearly states the tool's purpose: 'Run custom PromQL.' This specifies the verb ('Run') and resource ('custom PromQL'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from its siblings (like 'get_alerts' or 'run_check'), which would require a 5.
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 usage context with the guardrail ('approved must be True before execution') and explains the two modes based on the 'instant' parameter. This gives practical guidance on when and how to use the tool. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_alerts' or 'run_check' from the sibling list, which would be needed for 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 provided, the description carries full burden. It discloses some behavioral traits: it's a read operation (implied by 'return summarized results'), uses Prometheus query_range, and describes filter behavior for server_name/instance. However, it omits critical details like rate limits, authentication needs, error handling, or what 'summarized results' entails structurally.
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 well-structured with a purpose statement followed by a bulleted parameter guide and filter behavior explanation. Most sentences earn their place, though some redundancy exists (e.g., listing all time-offset parameters individually). It could be more front-loaded by emphasizing the check_id requirement earlier.
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 complexity (15 parameters, no annotations) but presence of an output schema, the description is largely complete. It thoroughly documents inputs and basic behavior. The output schema likely covers return values, so the description appropriately focuses on usage semantics. Minor gaps remain in behavioral transparency (e.g., error cases).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for all 15 parameters: explains required vs. optional inputs, gives examples (e.g., step: '1m, 5m, 15m'), clarifies priority rules (absolute vs. relative time, environment vs. env_hint), and documents filter interaction logic. This adds significant value beyond the bare 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 the tool's purpose with specific verbs ('run', 'return') and resources ('allowlisted check via Prometheus query_range', 'summarized results'). It distinguishes from siblings like 'run_all_checks' (single vs. all checks) and 'run_promql' (predefined checks vs. custom queries).
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 context through parameter explanations (e.g., 'when targeting one exact exporter endpoint' for 'instance'), but lacks explicit guidance on when to choose this tool over alternatives like 'run_all_checks' or 'run_promql'. No prerequisites or exclusions are stated.
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 provided, the description carries full burden for behavioral disclosure. It effectively describes key behaviors: parallel execution, fixed step parameter ('step is fixed to 5m'), and that provided step values are ignored. It also mentions controlling payload size as rationale. However, it doesn't cover other important behavioral aspects like error handling, performance implications, or what 'allowlisted' means in practice.
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 well-structured and concise. The first sentence states the core purpose. The second explains input equivalence to sibling tool. The note section efficiently covers the critical behavioral constraint about the step parameter. Every sentence earns its place with essential information, and the structure is front-loaded with the most important information first.
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 tool's complexity (14 parameters, parallel execution), no annotations, and 0% schema description coverage, the description does a good job with what it covers but leaves significant gaps. It explains the parallel execution and step constraint well, but doesn't cover most parameters, doesn't explain what 'allowlisted checks' means, and doesn't describe the output format (though an output schema exists, which helps). For a tool with this many parameters and no annotations, more comprehensive coverage would be expected.
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?
Schema description coverage is 0%, so the description must compensate. It provides valuable semantic context for 3 parameters: explains that 'server_name' and 'instance' are filter parameters, clarifies that 'step' is fixed at '5m' and any provided value is ignored. However, with 14 total parameters, it only covers 3 of them, leaving 11 parameters without semantic explanation in either schema or description.
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: 'Run all allowlisted checks in parallel for the same time range and filters.' It specifies the action ('run'), scope ('all allowlisted checks'), execution mode ('in parallel'), and constraints ('same time range and filters'). It also distinguishes from sibling 'run_check' by explaining it runs multiple checks instead of one.
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 for when to use this tool: for running multiple checks in parallel with shared filters. It explicitly references sibling tool 'run_check' and states inputs are equivalent, helping the agent understand the relationship. However, it doesn't specify when NOT to use this tool or mention alternatives beyond the basic comparison to run_check.
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:

[![MCP-Prometheus-Loki MCP server](https://glama.ai/mcp/servers/yeonkyu-git/MCP-Prometheus-Loki/badges/card.svg)](https://glama.ai/mcp/servers/yeonkyu-git/MCP-Prometheus-Loki)

Score Badge

Copy to your README.md:

[![MCP-Prometheus-Loki MCP server](https://glama.ai/mcp/servers/yeonkyu-git/MCP-Prometheus-Loki/badges/score.svg)](https://glama.ai/mcp/servers/yeonkyu-git/MCP-Prometheus-Loki)

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/yeonkyu-git/MCP-Prometheus-Loki'

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