openobserve-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct aspect of OpenObserve: streams, schema, org summary, logs, traces, metrics. Search vs. aggregate vs. query are clearly differentiated by descriptions, and search_traces vs. get_trace are separate listing vs. detail operations.
Naming Consistency5/5
All tool names use snake_case with a verb_noun structure (list_, get_, search_, aggregate_, query_). The verbs accurately reflect the operation, and the nouns denote the target resource. This is highly predictable.
Tool Count5/5
With 8 tools covering streams, schema, logs, traces, and metrics, the surface is well-scoped without being bloated. Each tool fills a necessary role for an observability MCP server.
Completeness5/5
The set provides a comprehensive read-only query surface: listing streams, inspecting schemas, searching and aggregating logs, listing traces with details, and querying metrics. No obvious dead ends or missing critical operations for the core domain.
Average 3.7/5 across 8 of 8 tools scored.
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 status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists what the summary includes but gives no information about side effects, permissions, output format, or how the data is aggregated. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a colon-separated list, highly concise and immediately clear. No redundant or filler content.
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?
While the tool is simple, the description covers the main elements of an organization summary but does not explain format, units, or caveats. For a tool with no output schema, it provides enough for basic understanding but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description mentions the content areas covered. Since there are no parameters to document, the description provides adequate semantic context for the tool's function.
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 organization summary' and lists specific data points (stream count, storage, pipelines, alerts, dashboards), making its purpose explicit. It distinguishes itself from sibling tools that focus on individual entities like streams, traces, or logs.
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 guidelines are provided. The description does not explain when to use this summary tool versus listing streams or searching logs, and there is no mention of scenarios where it should be preferred or avoided.
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 burden of disclosing behavior. It adds useful facts like 'newest first' and 'optional SQL WHERE clause', but does not address response format, pagination, error behavior, or time range semantics beyond what the schema already specifies. It provides some value but is 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 a single, front-loaded sentence that conveys core functionality and two key behaviors (SQL filter, newest first). Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, no output schema), the description covers the main action but omits details about return values, limit application, or error handling. The schema fills parameter gaps, but the description could be stronger by adding expected output or when to prefer this over sibling search/aggregation tools.
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 does not add extra parameter-level meaning; it merely restates the optional SQL WHERE clause, which is already detailed in the query parameter description. No boost needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('search') and resource ('logs'), and adds valuable detail about the optional SQL WHERE clause and newest-first ordering. This clearly differentiates it from sibling tools like search_traces (traces) and aggregate_logs (aggregation).
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 gives no explicit guidance on when to use this tool versus alternatives. It implies usage for searching logs with filtering, but does not mention when not to use it, prerequisites, or relationships to siblings like search_traces or aggregate_logs.
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 disclosing behavior. It only says 'list recent traces' and does not specify ordering, default time window, pagination behavior, or error handling. This is minimal beyond the basic purpose.
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 primary action and resource, then lists the key output fields. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description and schema together cover the basic purpose and all inputs, but with no output schema and no annotations, the description lacks contextual details like sorting, pagination, or typical usage patterns. It is adequate but has room for improvement.
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 input schema already fully documents all five parameters, including defaults and examples. The description adds no parameter-specific meaning, matching the baseline of 3.
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 resource ('recent traces'), and specifies the returned fields (root operation, duration, participating services). This distinguishes it from sibling tools like get_trace (single trace) and search_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing recent traces, but provides no explicit when-to-use guidance, exclusions, or alternatives. It does not mention when to prefer this over get_trace or search_logs, leaving some ambiguity.
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 only states the action ('get') without mentioning read-only semantics, permissions, rate limits, error behavior, or response format. The lack of such details leaves users guessing about operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the tool's simplicity, stating the core function in a clear and direct manner.
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, parameters are fully covered by the schema, and the description provides a clear indication of the return content (field names and types). No output schema exists, but the description sufficiently conveys what to expect. It lacks only minor additional context about stream_type distinctions, which the schema already handles.
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 parameters are already documented. The description adds the high-level purpose ('field names and types') but does not elaborate on the stream_type parameter or its default. Baseline of 3 is appropriate since the schema carries 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 tool retrieves field names and types for a stream, which is a specific verb+resource combination. It distinguishes itself from siblings like list_streams (which lists streams) and search_logs (which searches logs) by focusing on schema metadata.
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 when you need stream schema information, but provides no explicit guidance on when to use it over alternatives, nor any exclusions. It is not misleading, but lacks proactive usage 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 provided, the description carries the burden of behavioral disclosure. The verb 'list' implies a read-only, non-destructive operation, but the description does not explicitly confirm safety, permissions, or output format. It provides minimal behavioral context beyond the obvious.
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, focused sentence that immediately states the purpose with no filler or redundant detail. The structure is clean and front-loaded with the verb.
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 listing tool with one optional parameter, the description is adequate. It implies a list output and the schema covers filtering. However, it does not explicitly mention all stream types supported by the enum, and there is no output schema, but the tool's simplicity makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter stream_type with an enum and description, so the description adds no additional semantic value. The parenthetical in the description lists a subset of enum values, but it does not explain parameter behavior or format 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 uses a specific verb ('list') and a clear resource ('available streams'), with a parenthetical enumerating common stream types. This directly states what the tool does and distinguishes it from siblings like search_logs or aggregate_logs, which operate on stream data rather than enumerating streams.
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. No alternatives, prerequisites, or exclusions are mentioned. The sibling tools suggest different use cases, but the description does not connect to them or provide any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must shoulder the full burden of behavioral disclosure. It does mention that results are ordered by start time and that it returns every span, but it omits critical behavioral details such as pagination, response format, error handling, or time-range limits. Since this is a read-only retrieval, the safety profile is inferred, but the lack of concrete details about the output and edge cases leaves significant gaps.
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 (12 words) that immediately conveys the core function. It front-loads the key information and contains no filler. Every word adds value, making it an ideal example of concise, well-structured documentation.
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 tool with 4 parameters and no output schema, the description provides the essential purpose but lacks details about the return structure (e.g., what a span consists of), potential limitations, or how it handles missing traces. It is adequate for basic understanding but misses important contextual information that a complex observability tool might require. The schema helps with parameters, but the absence of output schema and richer behavioral context leaves the description 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of the parameters (stream, end_time, trace_id, start_time) with clear explanations. The tool description itself does not add any additional parameter semantics. Since schema coverage is high, the baseline of 3 applies; the description neither enhances nor detracts from the parameter understanding.
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 states exactly what the tool does: 'Get every span of a single trace, ordered by start time.' It specifies the action (get), the resource (spans of a single trace), and a distinguishing detail (ordered by start time). This clearly differentiates it from the sibling tool 'search_traces', which likely finds traces rather than retrieving all spans of a known trace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: when you have a specific trace ID and need all its spans. However, it does not explicitly mention when not to use this tool or suggest alternatives like 'search_traces' for finding traces. The context is clear but lacks exclusions or explicit alternative guidance, which prevents 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?
No annotations are provided, so the description carries the full burden. It states the tool queries metrics over a range and references Prometheus query_range, which implies a read-only operation, but it does not disclose output format, time-range limits, pagination, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and resource. There is no redundancy or filler; 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?
With no output schema and no annotations, the description could usefully mention the return format (e.g., Prometheus matrix) and any time-range constraints. The schema documents parameters well, but the overall tool context is under-specified for an agent that needs to understand what to expect from the result.
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 each parameter is already documented. The description adds only the 'PromQL' and 'time range' context, which is already reflected in the schema descriptions, adding minimal semantic value 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 uses a specific verb and resource: 'Query metrics with PromQL over a time range', which clearly identifies the tool's purpose and distinguishes it from log/trace siblings. The parenthetical 'Prometheus query_range' further anchors the exact API behavior.
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: use this tool to query Prometheus metrics over a time range. It does not explicitly mention when not to use it or name alternatives, but the metric/time-range framing is enough to guide tool selection among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It usefully discloses the stream-substitution behavior, but it does not state whether the operation is read-only, how results are returned, or any query limitations. The aggregation phrasing implies a safe read, but richer 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The first sentence states the core function, and the second provides a critical usage detail. It is front-loaded and every word 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 has five parameters and no output schema, but the schema descriptions cover all parameters and the description explains the key substitution mechanism. It does not detail return values or error behavior, but for an aggregation query the return shape is largely determined by the user's SQL, so the description plus schema are sufficient for an agent to 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 coverage is 100%, so the baseline is 3. The description adds valuable meaning beyond the schema by explaining that the literal token `stream` in the SQL is replaced with the real stream name, which is essential for correctly constructing both the `sql` and `stream` parameters.
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 a specific verb and resource: 'Run an aggregation query' and enumerates the supported operations (COUNT, AVG, SUM, GROUP BY). This clearly distinguishes it from sibling search/query tools and leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for aggregations, but it does not explicitly state when to prefer this tool over alternatives like search_logs or query_metrics. There are no when-not-to-use instructions or direct sibling comparisons, so the guidance is only implicit.
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:

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

Score Badge

Copy to your README.md:

[![OpenObserve-mcp MCP server](https://glama.ai/mcp/servers/devShahriar/OpenObserve-mcp/badges/score.svg)](https://glama.ai/mcp/servers/devShahriar/OpenObserve-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/devShahriar/OpenObserve-mcp'

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