observability-mcp

Server Quality Checklist

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

Latest release: v3.9.4
Disambiguation5/5
Each tool targets a distinct observability task: anomaly detection (live vs historical), health verdict vs raw queries, topology vs blast-radius, utilities (IP enrichment, postmortem generation), and discovery (services, sources). No two tools have overlapping purposes.
Naming Consistency5/5
All 12 tools follow a consistent verb_noun pattern in snake_case (e.g., detect_anomalies, get_service_health, list_sources). No mixing of styles or ambiguous verbs.
Tool Count5/5
12 tools is well-scoped for an observability server covering health, anomaly detection, raw data queries (metrics/logs/traces), topology, utilities, and postmortem generation. Each tool serves a clear purpose without redundancy.
Completeness4/5
The tool set covers core observability workflows: discovery, health assessment, raw data inspection, anomaly detection, and postmortem. A minor gap is the lack of a tool to list available metric names per service (since query_metrics requires a known metric name), but this is not critical.
Average 4.8/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 332 commits in the last 12 weeks
- Last stable release on August 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it returns a time-series of scores and explains meanings of empty results, providing some additional context beyond annotations.
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, front-loads the main purpose, and includes usage, prerequisites, behavior, result, and related tools in a single well-structured paragraph with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 params and no output schema, the description explains the return type ('time-series of scores'), empty result meaning, and prerequisites. It is largely complete, though more details on the exact response format could be beneficial.
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 baseline is 3. The description does not add significant detail beyond what the schema provides for each parameter. Each parameter has a brief description in the schema, and the description adds overall context but not per-parameter semantics.
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 explicitly states 'Replay historical anomaly scores for a service from the TSDB', providing a specific verb and resource. It distinguishes itself from sibling tool 'detect_anomalies' by mentioning it is for live scores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios ('post-mortem reconstruction, trend analysis') and mentions prerequisites (OMCP_ANOMALY_HISTORY_REMOTE_WRITE and Prometheus source). It also explains the meaning of an empty result and relates to sibling tools for live scores.
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?
Declares read-only, no side effects, which matches annotations (readOnlyHint, idempotentHint). Adds detail about return structure (name, sources, available signals). No contradictions.
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?
Front-loaded with purpose, followed by usage, behavior, and output summary. Every sentence adds value; no wasted words.
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?
Tool has one optional parameter, no output schema, but description explains return structure. Annotations cover safety. No gaps for agent decision-making.
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 coverage is 100%; the description's mention of the filter parameter mirrors the schema's description exactly. No additional semantics beyond what 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?
Clearly states verb 'discover', resource 'service names', and scope 'aggregated across every connected backend'. Distinguishes from siblings by naming alternative tools and their purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call before query_metrics, query_logs, and get_service_health to obtain exact case-sensitive names. Also references related tools list_sources and get_service_health, giving clear when-to-use and alternatives.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds output shape, filter composition rules, and limiting behavior, providing useful context beyond annotations.
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?
Single paragraph that packs purpose, usage, behavior, output, filter details, and related tools without wasted words. Front-loaded with main action and outcome.
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?
Covers all parameters and output shape. Lacks explicit return value details, but given no output schema, the description provides sufficient context for typical use. Could mention pagination or total count behavior, but not essential.
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 coverage is 100%, but description adds significant value: explains filter composition, gives examples of resource kinds (Kubernetes, other connectors), and specifies default and max for limit. Goes well beyond schema alone.
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?
Clearly states 'Return the infrastructure topology graph' with specific verb and resource. Differentiates from siblings by mentioning related tools (get_blast_radius, list_sources) and their distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'When to use' with reasoning about workload relationships and scope belonging. Pairs with get_blast_radius and mentions list_sources for discovery, giving clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: read-only, no side effects; handling of absent data (null summary, note); groupBy behavior; units; error responses. Annotations already declare readOnlyHint=true, but description enriches with concrete edge cases.
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?
Front-loaded with purpose, then usage guidance, prerequisites, and behavior details. Every sentence adds value; no redundancy. Well-organized and appropriately sized.
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 no output schema and 7 parameters with nested objects, the description covers return format, edge cases, groupBy behavior, error handling, and units. It is comprehensive for the tool's complexity.
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 coverage is 100%, so baseline is 3. Description adds context about prerequisites and metric list but does not add new semantics beyond the detailed schema descriptions.
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 fetches raw time-series for one metric of one service, with specific verb and resource. It distinguishes from siblings like get_service_health and detect_anomalies by scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('when you need actual numeric values or trend'), when-not-to-use (use get_service_health for health verdict, detect_anomalies for misbehaving services), and prerequisites (get service name from list_services, choose metric from list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent. The description adds detailed behavioral traits: no side effects, statistical method (z-score analysis), correlation of metrics and logs, and handling of no anomalies (empty list, not an error). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single cohesive paragraph that effectively front-loads the purpose. It is reasonably concise, though could be slightly more structured (e.g., bullet points).
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?
Despite lacking an output schema, the description fully explains the return value (list of anomalies with fields like service, severity, deviation, explanation) and edge case (empty list). Given the tool's complexity and sufficient annotations, the description is 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?
Schema coverage is 100%, so baseline is 3. The description adds context beyond schema by explaining the statistical method (z-score) and the meaning of sensitivity levels, but the schema already describes each parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Scan one or all monitored services for abnormal behavior') and output ('return the findings ranked by severity'), distinguishing it from siblings like get_service_health and query_metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage context: 'the entry point for 'is anything wrong anywhere?' triage.' It also recommends follow-up actions using get_service_health, query_metrics, and query_logs, and lists related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint, idempotentHint), the description discloses critical behavior: using local offline dataset by default, optional RDAP fallback, handling of invalid entries (return found=false), transient rows due to rate limits, and caching. No contradiction with annotations.
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 somewhat lengthy but well-structured: core function first, then usage, then behavioral details, then special cases. It is front-loaded with the main purpose. Could be slightly trimmed, but every sentence adds value.
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?
With no output schema, the description thoroughly explains the return format (one row per IP, found flag, summary, transient, note). It covers error handling, rate limiting, and configuration dependencies. Complete for a single-parameter tool.
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 input schema fully describes the 'ips' parameter with a note about invalid entries. The description adds contextual value: both IPv4 and IPv6 are supported, invalid entries do not fail the batch, and the default local vs RDAP behavior. Schema coverage is 100%, so baseline 3; the extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it resolves IPs to geo, ASN/org, and hosting/proxy flag. It provides specific use-case scenarios ('where are these visitors from?', 'which of these IPs are bots?') and distinguishes from sibling tools like query_logs by explaining the enrichment purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (e.g., answering geolocation or bot detection questions) and when not to pre-filter v6. It mentions the local dataset vs RDAP fallback, how to handle transient rows (retry), and the 1000-item limit. Provides meaningful context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only behavior (consistent with annotations), output capped limits (timeline 20 rows, blast-radius 30 nodes, 10 traces), and that JSON shape carries full data. No contradiction with annotations.
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?
Every sentence contributes: purpose, usage, prerequisites, behavior, output detail, and related tools. No fluff, well-organized in a few lines.
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 no output schema, description explains return format (markdown default, JSON optional), caching, and limitations. Prerequisites and behavior covered. Could specify report structure slightly more but adequate for completeness.
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 covers all three parameters with descriptions. The description adds value by explaining format default ('markdown') and that JSON returns structured shape, plus duration default '1h'. Enhances parameter understanding without redundancy.
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 stitches gateway primitives into a single markdown post-mortem report for one service over a given window. It distinguishes from siblings by listing the primitives combined (anomaly history, blast-radius, traces, log highlights).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: after an incident, for a concise document instead of individual tools. Provides prerequisites for each primitive (e.g., anomaly history requires OMCP_ANOMALY_HISTORY_REMOTE_WRITE, traces require Tempo/Jaeger). Also lists related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, no side effects, which the description confirms and adds details like error handling (no matches yields zeroed summary, unreachable backend yields structured error). No contradictions.
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?
Well-structured with clear sections (purpose, usage, golden rule, prerequisites, behavior, returns). Slightly long but every sentence adds value; could be tightened slightly.
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?
Covers return format, error scenarios, redaction behavior, and prerequisites. Given 9 parameters, nested objects, and no output schema, the description provides sufficient context for correct usage.
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 coverage is 100% with detailed descriptions. The description adds high-level guidance (e.g., 'aggregate' to get numbers, context limit warning), but much is already in schema. The added value is marginal but present.
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 it fetches recent log entries for ONE service with a pre-computed summary. It distinguishes from siblings like query_metrics and query_traces by specifying log-specific behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (inspect logs, investigate anomalies) and when not to use (metrics use query_metrics). Provides prerequisite (get service name from list_services) and a 'golden rule' for efficient usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds: 'Behavior: read-only, no side effects.' It also details resource resolution, host determination via RUNS_ON, bucketing by ownership root, and error handling. This adds substantial context beyond annotations.
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 well-structured paragraph that front-loads the core purpose, then provides details on usage, behavior, and related tools. Every sentence adds value with no redundancy.
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 has one parameter fully described in schema, rich annotations, and the explanation of output structure (bucketed by ownership root), the description is complete for an agent to select and invoke the tool correctly.
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 100% for the single parameter 'resource'. The description adds examples and explains resolution behavior (canonical id, exact name, unique substring). Since the schema already fully describes the parameter, the added value is moderate but significant.
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: given a resource, return who else fails if its underlying host(s) fail. It specifies the verb 'return', the resource context, and the relationship (RUNS_ON). It also distinguishes from siblings by mentioning related tools like get_topology and get_service_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit guidance: 'When to use: cross-cutting RCA — when several services degrade together and you suspect a shared host.' It also explicitly names alternative tools: 'Related: get_topology for the full graph; get_service_health for the per-service verdict on each co-tenant.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds that it's read-only with no side effects, details return fields (score, status, contributing metrics, error summary, anomalies, correlations), and clarifies behavior for services with no data (explanatory result not exception).
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?
Description is concise with no filler. Front-loaded purpose and usage, structured logically. Every sentence adds value.
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?
Tool has 1 parameter, no output schema, but description fully covers purpose, usage, behavior, and return fields. No gaps given the complexity.
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 covers the 'service' parameter with clear description and example. Description reinforces the need for exact case-sensitive name from list_services. Adds useful context beyond schema for one parameter.
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 explicitly states it produces a single aggregated health verdict for one service using metrics and logs. It distinguishes from sibling tools like query_metrics/query_logs and detect_anomalies, making the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use ('fastest way to answer is this service healthy'), when not (alternatives named), and prerequisites (get service name from list_services). Comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, adds that it never throws for unreachable backends (reports down), explains that backend URL is intentionally hidden for security, and confirms read-only with no side effects.
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?
Well-structured with clear sections: purpose, when-to-use, behavior, return info, exception handling, related tool. Efficiently covers all needed information.
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?
Complete for a tool with no parameters and no output schema. Covers input, behavior, output, error handling, and security. Points to sibling for further reference.
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?
No parameters, so baseline 4. Description adds value by detailing return fields (name, type, signal types, status) without needing parameter info.
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?
Clearly states it lists configured observability backends and their reachability, with specific verbs and resource. Distinguishes from sibling 'list_services' by noting what each shows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: call first to learn source names and health before passing 'source' to other tools, or to debug no data queries. Mentions related tool 'list_services'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Behavior: read-only' aligning with annotations (readOnlyHint=true). Adds details about filter language, errorsOnly behavior, default limit, and what happens if no backend is configured. Provides useful behavioral context beyond annotations.
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?
Well-structured with clear sections. Purpose is front-loaded. Every sentence adds value; no repetition or fluff. Appropriate length for the complexity of the 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?
Description covers return value format (ranked summaries with p50/p95), parameter details, prerequisites, and error case. Despite no output schema, the description provides sufficient contextual completeness for correct 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that filter accepts native query language (e.g., TraceQL) and mentions default limit, going beyond individual parameter descriptions. However, it could have included more detail on duration format or error status meaning.
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?
Describes specific verb 'Query' and resource 'distributed traces for a service' with output details (ranked summaries, aggregates). Clearly distinguishes from sibling tools like query_logs and query_metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (tail-latency, call chains, anomaly follow-up), prerequisites (service name from list_services, connector configuration), and a failure mode (no backend configured). Offers clear usage context.
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:

[![observability-mcp MCP server](https://glama.ai/mcp/servers/ThoTischner/observability-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ThoTischner/observability-mcp)

Score Badge

Copy to your README.md:

[![observability-mcp MCP server](https://glama.ai/mcp/servers/ThoTischner/observability-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ThoTischner/observability-mcp)

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/ThoTischner/observability-mcp'

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