This is a read-only MCP server for OpenObserve Community Edition that enables querying and analysis of logs, traces, dashboards, and stream metadata via the OpenObserve REST API from local MCP clients like Claude and Codex.
list_streams: Browse available streams in your organization, filterable by keyword and stream type, with sorting and pagination support.
get_stream_schema: Retrieve field/schema information for a specific stream, with a configurable limit on fields to inspect.
search_logs: Run SQL queries against logs supporting WHERE, ORDER BY, GROUP BY, and aggregate functions. Includes token-efficient output formats (records or columns) and Kubernetes-compact record profiles.
search_around: Fetch log records surrounding a specific entry by its _timestamp value for contextual investigation.
search_values: Discover distinct field values for a stream over a time range, with optional filtering and keyword search.
list_dashboards: List all dashboards in your organization, with optional filtering by title or folder.
get_dashboard: Retrieve the full definition of a specific dashboard by its ID.
get_latest_traces: Fetch the most recent trace data from a trace stream within a given time range, with optional filtering.
Supports basic and bearer authentication, optional organization specification, SSL verification control, timeout settings, and multiple deployment options (uvx, local binary, or Docker).
stdio MCP server for OpenObserve Community Edition, using only the regular REST API.
This package is designed for local MCP clients such as Claude and Codex.
What it is:
stdio only
Community Edition only
read-only only
regular OpenObserve REST API only
no native /mcp endpoint
The server can boot without an active OpenObserve configuration so hosted MCP platforms can start it,
but every tool call still requires a reachable external OpenObserve instance configured via OO_BASE_URL
and credentials.
uvx --from openobserve-community-mcp openobserve-mcp init-configThis creates a sample config at:
~/.config/openobserve-mcp/config.envEdit it:
vim ~/.config/openobserve-mcp/config.envExample:
OO_BASE_URL=https://openobserve.example.com
# Optional if the credentials have access to exactly one organization.
# OO_ORG_ID=default
OO_AUTH_MODE=basic
OO_USERNAME=your_username
OO_PASSWORD=your_password
OO_TIMEOUT_SECONDS=20
OO_VERIFY_SSL=trueclaude mcp add -s user openobserve-community -- uvx --from openobserve-community-mcp openobserve-mcpcodex mcp add openobserve-community -- uvx --from openobserve-community-mcp openobserve-mcpOpenCode configures MCP servers under mcp in its config file. According to the official docs,
you can add MCP servers in your global config at ~/.config/opencode/opencode.json or in a
project-level opencode.json.
See:
If you created the sample config with openobserve-mcp init-config, you can point OpenCode to it:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"openobserve-community": {
"type": "local",
"command": ["uvx", "--from", "openobserve-community-mcp", "openobserve-mcp"],
"enabled": true,
"environment": {
"OO_CONFIG_FILE": "/absolute/path/to/config.env"
}
}
}
}You can also inline the OpenObserve settings directly in the OpenCode MCP config:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"openobserve-community": {
"type": "local",
"command": ["uvx", "--from", "openobserve-community-mcp", "openobserve-mcp"],
"enabled": true,
"environment": {
"OO_BASE_URL": "https://openobserve.example.com",
"OO_AUTH_MODE": "basic",
"OO_USERNAME": "your_username",
"OO_PASSWORD": "your_password"
}
}
}
}OpenCode's MCP docs also support optional enabled, environment, and timeout fields for local
servers if you want to tune startup behavior.
Related MCP server: OpenTelemetry MCP Server
This repository also publishes a container image for Docker-based MCP clients and Glama deployments:
docker run --rm -i \
-e OO_BASE_URL \
-e OO_ORG_ID \
-e OO_AUTH_MODE \
-e OO_USERNAME \
-e OO_PASSWORD \
-e OO_TOKEN \
-e OO_TIMEOUT_SECONDS \
-e OO_VERIFY_SSL \
ghcr.io/alilxxey/openobserve-community-mcp:latestOO_ORG_ID is optional when the credentials only have access to one organization.
Use OO_USERNAME and OO_PASSWORD for basic auth, or OO_TOKEN for bearer auth.
The container can start without these values for hosted MCP platforms, but tool calls will fail until
you configure a real external OpenObserve instance.
Default config path:
~/.config/openobserve-mcp/config.envSupported settings:
OO_BASE_URL
OO_ORG_ID optional
OO_AUTH_MODE
OO_USERNAME and OO_PASSWORD for basic auth
OO_TOKEN for bearer auth
OO_TIMEOUT_SECONDS
OO_VERIFY_SSL
OO_CONFIG_FILE optional explicit path to a config file
Config precedence:
explicit OO_CONFIG_FILE
~/.config/openobserve-mcp/config.env
legacy .env.local in the current directory
process environment overrides file values
You can also pass config directly via MCP client env settings.
claude mcp add -s user openobserve-community \
-e OO_BASE_URL=https://openobserve.example.com \
-e OO_AUTH_MODE=basic \
-e OO_USERNAME=your_username \
-e OO_PASSWORD=your_password \
-- uvx --from openobserve-community-mcp openobserve-mcpcodex mcp add openobserve-community \
--env OO_BASE_URL=https://openobserve.example.com \
--env OO_AUTH_MODE=basic \
--env OO_USERNAME=your_username \
--env OO_PASSWORD=your_password \
-- uvx --from openobserve-community-mcp openobserve-mcpIf you prefer to keep everything in OpenCode config instead of a separate config.env, use:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"openobserve-community": {
"type": "local",
"command": ["uvx", "--from", "openobserve-community-mcp", "openobserve-mcp"],
"enabled": true,
"environment": {
"OO_BASE_URL": "https://openobserve.example.com",
"OO_AUTH_MODE": "basic",
"OO_USERNAME": "your_username",
"OO_PASSWORD": "your_password"
}
}
}
}Official OpenCode references:
list_streams
get_stream_schema
search_logs
search_around
search_values
list_dashboards
get_dashboard
get_latest_traces
If you prefer a persistent local binary instead of uvx:
uv tool install openobserve-community-mcpThis installs the openobserve-mcp command into your user-level uv tools directory.
claude mcp add -s user openobserve-community -- openobserve-mcpcodex mcp add openobserve-community -- openobserve-mcpYou can also run the server directly:
openobserve-mcpThis mode may require ~/.local/bin to be present in your PATH.
If openobserve-mcp is not found, either:
add ~/.local/bin to your PATH; or
use the recommended uvx --from openobserve-community-mcp openobserve-mcp launch mode instead.
Get a dashboard definition by id.
| Name | Required | Description | Default |
|---|---|---|---|
| dashboard_id | Yes | ||
| include_raw | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, error handling, or permissions. It relies solely on the name and minimal text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that conveys the core action without superfluous words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema presence (though not shown), the description lacks detail on output format, error cases, and parameter use. It is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage on parameters, and the tool description adds no explanation for dashboard_id or include_raw. The description provides no added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a dashboard definition by identifier. This is a specific verb-resource pair distinct from siblings like list_dashboards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific dashboard is needed by id, but lacks explicit guidance on when not to use or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest trace data from a trace stream. start_time and end_time accept Unix timestamps in seconds, milliseconds, microseconds, or nanoseconds and are normalized to microseconds.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_name | Yes | ||
| start_time | Yes | ||
| end_time | Yes | ||
| size | No | ||
| offset | No | ||
| filter_query | No | ||
| timeout | No | ||
| include_raw | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral detail: that timestamps are accepted in multiple units and normalized to microseconds. However, it does not disclose other important traits like read-only nature, authentication needs, or rate limits, which are not covered by annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose. Every word earns its place. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain key parameters like pagination (offset/size), filtering (filter_query), timeout, and raw flag. The tool has 8 params and 3 required; the description covers only the timestamp normalization detail, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 only explains the timestamp format for start_time and end_time, but omits semantics for stream_name, size, offset, filter_query, timeout, and include_raw. Most parameters remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the latest trace data') and the resource ('trace stream'). It distinguishes the tool from siblings like search_logs or search_around by targeting trace data specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or exclusions. The description is silent on decision-making for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get schema information for a specific stream. Use this first to confirm real field names before writing SQL; many log streams expose message rather than log. Increase fields_limit to inspect more fields from large schemas.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_name | Yes | ||
| fields_limit | No | ||
| include_raw | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals that many log streams expose 'message' rather than 'log' and recommends fields_limit adjustment, adding behavioral context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy: purpose, usage reason, and parameter hint. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 params, 0% schema coverage, and an output schema, the description covers main purpose and one parameter well. Missing explanation for include_raw, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains fields_limit's purpose and implies stream_name's role. It does not explain include_raw, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets schema information for a specific stream and provides context about log streams vs 'message' field, distinguishing it from siblings like search_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises using this first to confirm field names before SQL and suggests increasing fields_limit for large schemas, but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List dashboards in the current organization.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | ||
| title | No | ||
| page_size | No | ||
| include_raw | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits like read-only nature, pagination, or side effects. It only says 'list', which implies read-only, but provides no details on rate limits, data format, or scope beyond 'current organization'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified for a tool with four parameters. It lacks structure and does not earn its place by adding sufficient value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage and no annotations, the description is incomplete. It omits parameter explanations and behavioral context. While output schema exists, the description still fails to address usage and parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation for any of the four parameters (folder, title, page_size, include_raw). It provides no semantics beyond what the schema types and defaults convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'dashboards' with scope 'in the current organization'. It distinguishes from sibling 'get_dashboard' by implying listing many rather than one, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings like 'get_dashboard' or other listing tools. The description does not specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List streams available in the current organization.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_type | No | logs | |
| keyword | No | ||
| offset | No | ||
| limit | No | ||
| sort | No | name | |
| include_raw | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It does not mention read-only nature, authentication needs, rate limits, or pagination behavior. The phrase 'available in the current organization' implies scope but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly minimal. It could provide more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with no schema descriptions, no annotations, and an output schema not elaborated, the description is incomplete. It fails to cover parameter meaning, expected behavior, or return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 6 parameters with 0% description coverage (no parameter descriptions). The tool description adds no meaning for any parameter, leaving the agent with no understanding of stream_type, keyword, offset, limit, sort, or include_raw.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists streams in the current organization. It distinguishes from siblings like search_logs and get_stream_schema by focusing on listing available streams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_stream_schema for schema information, search_logs for searching log content). The description only states what it does, not when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch records around a specific log entry. key accepts Unix timestamps in seconds, milliseconds, microseconds, or nanoseconds for convenience, but the best input is the exact _timestamp returned by search_logs; otherwise OpenObserve may return no nearby rows. output_format can be 'records' or 'columns' for a more token-efficient table shape. record_profile can be 'generic' or 'kubernetes_compact'.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_name | Yes | ||
| key | Yes | ||
| size | No | ||
| regions | No | ||
| timeout | No | ||
| output_format | No | records | |
| record_profile | No | generic | |
| include_raw | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that input timestamps can be in multiple units and mentions output format options. However, it does not specify whether the operation is read-only, side effects, or authentication requirements, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding essential information without redundancy. The purpose is stated first, followed by important parameter details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description leaves many parameters undocumented and does not clarify when to use this tool versus its sibling search_logs. Given 8 parameters and only 3 explained, the description is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage. The description explains three parameters (key, output_format, record_profile) with practical details, but the remaining five parameters (stream_name, size, regions, timeout, include_raw) are unexplained, so the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches records around a specific log entry, which is a specific verb and resource. It distinguishes from sibling tools like search_logs by focusing on nearby records rather than general log search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using the `key` parameter, including acceptable formats and the recommendation to use the exact `_timestamp` from search_logs. However, it does not explicitly state when to prefer this tool over alternatives like search_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a full SQL search against OpenObserve logs. Example row query: SELECT _timestamp, message FROM "my_stream" ORDER BY _timestamp DESC LIMIT 20. Example aggregate query: SELECT level, count(*) AS cnt FROM "my_stream" GROUP BY level ORDER BY cnt DESC LIMIT 20. Prefer double quotes around stream names in SQL when in doubt, and confirm actual field names with get_stream_schema instead of assuming a log column. start_time and end_time accept Unix timestamps in seconds, milliseconds, microseconds, or nanoseconds and are normalized to microseconds. The limit parameter sets the API page size; if your OpenObserve/DataFusion setup still complains about ORDER BY without a SQL LIMIT, add an explicit LIMIT to the SQL as well. output_format can be 'records' or 'columns'; 'columns' is especially useful for wide SELECT * queries and can save roughly 35-40% tokens. record_profile can be 'generic' or 'kubernetes_compact'; the Kubernetes compact profile trims common noisy metadata fields such as pod labels and pod IP metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| start_time | Yes | ||
| end_time | Yes | ||
| limit | No | ||
| offset | No | ||
| use_cache | No | ||
| timeout | No | ||
| output_format | No | records | |
| record_profile | No | generic | |
| include_raw | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: time normalization, limit as page size, output format token savings, record profiles, and advice on SQL syntax. This provides a rich understanding of tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but every sentence adds practical value, with examples and tips well integrated. It could be slightly more concise, but the structure is logical and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no annotations, the description covers the core usage comprehensively. Some less common parameters are omitted, but the most critical ones are addressed. Output schema exists, so return values are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining key parameters (sql, start_time, end_time, limit, output_format, record_profile) in detail. However, offset, use_cache, timeout, and include_raw are not described, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a full SQL search against OpenObserve logs, with specific examples of row and aggregate queries. It is a specific verb+resource combination that distinguishes it from other search tools like search_around or search_values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus its siblings. It only provides tips on SQL syntax and field names, but does not clarify when to prefer search_logs over search_around or search_values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get distinct field values for a stream over a time range. stream_name is the raw stream name path segment, for example my_stream; do not quote it like SQL. fields is a comma-separated field list. filter_query uses OpenObserve's _values filter syntax, e.g. kubernetes_pod_namespace=litellm. Simple SQL-like equality such as kubernetes_pod_namespace='litellm' is normalized automatically. start_time and end_time accept Unix timestamps in seconds, milliseconds, microseconds, or nanoseconds and are normalized to microseconds. In this tool, total means the number of field groups returned, not the total number of matching log records.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_name | Yes | ||
| fields | Yes | ||
| start_time | Yes | ||
| end_time | Yes | ||
| size | No | ||
| offset | No | ||
| filter_query | No | ||
| keyword | No | ||
| regions | No | ||
| timeout | No | ||
| no_count | No | ||
| include_raw | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It explains that times are normalized to microseconds, filter_query supports SQL-like equality that is normalized automatically, and the meaning of 'total' differs from typical log record counts. It implies the tool is read-only but does not explicitly state idempotency or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with purpose. It uses multiple sentences but each adds value. It could be more structured (e.g., bullet points) but is still clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters, an output schema (which reduces need to describe return values), and moderate complexity, the description covers the critical parameters for usage but omits many optional ones. This is sufficient for basic use but incomplete for full agent autonomy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 only 4 out of 12 parameters (stream_name, fields, filter_query, start_time, end_time) with meaningful details. Parameters like size, offset, keyword, regions, timeout, no_count, and include_raw are not mentioned at all, leaving significant gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves distinct field values for a stream over a time range, with a specific verb ('get') and resource ('field values for a stream'). It includes examples, making the purpose unambiguous and distinct from sibling tools like search_logs or search_around.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific usage details: how to specify stream_name (raw path, no quoting), fields (comma-separated), filter_query syntax with an example, and time units. It explains the meaning of 'total' in this context. However, it does not explicitly state when to use this tool versus alternatives like search_logs, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_dashboardget_latest_tracesget_stream_schemalist_dashboardslist_streamssearch_aroundsearch_logssearch_valuesScored across 8 tools
Each tool has a distinct purpose, but search_logs and search_around both target log entries and could be confused without reading descriptions carefully. However, descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern using snake_case, with verbs like get, list, search applied appropriately.
With 8 tools covering dashboards, streams, logs, traces, schema, and values, the count is well-suited for an observability MCP server.
The tool set covers key querying operations but lacks lifecycle management (create/update/delete) for dashboards and streams, and there is no dedicated search_traces tool beyond get_latest_traces.
Access New Relic observability data through MCP - query metrics, logs, traces, entities, and more
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Cloud hosted Okahu MCP server that helps you manage genAI trace data
