Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@originchain/telemetry-mcp Analyze the recent incident in the checkout service and show the trace chain."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives an AI agent OriginChain's telemetry tools: log patterns, semantic incident analysis, distributed traces and service graphs.
Works with Claude Desktop, Cursor, Continue, Cline, Zed AI, and anything else that speaks the Model Context Protocol.
There are two, and they do different jobs.
Package | Talks to | Tools |
your database | ask, SQL, vector search, full-text, schemas | |
| the telemetry agent | log volume, patterns, incidents, traces, service graph |
They do not conflict. Configure both if you want both.
Related MCP server: Spyglass AI MCP Server
npm install -g @originchain/telemetry-mcpOr let your MCP host fetch it on demand with npx, as below.
The telemetry agent normally runs inside a private network, so you reach it through a port-forward. Point this at wherever that forward listens.
Claude Desktop, in claude_desktop_config.json:
{
"mcpServers": {
"originchain-telemetry": {
"command": "npx",
"args": ["-y", "@originchain/telemetry-mcp"],
"env": {
"OC_TELEMETRY_AGENT": "http://127.0.0.1:8892"
}
}
}
}Cursor, in .cursor/mcp.json, uses the same shape.
Variable | Default | Meaning |
|
| Base URL of the telemetry agent |
|
| Per-call timeout in milliseconds |
Tool | Use it for |
| Total volume and distinct pattern count |
| Highest-volume log patterns |
| Meaning-based search, finds related patterns sharing no keywords |
| The actual recent log lines, with real values rather than templates |
| Top error patterns in a window, with the window's total volume |
| One call fusing semantic cluster, latest occurrence, trace chain, service graph and rate anomaly |
| Who calls whom, with call counts |
| Keyword search over log template text |
| Every span of one distributed trace |
| One read-only SELECT for a specific filtered lookup |
Two notes worth knowing, because they change the answers you get.
Do not filter on severity for a loose "any errors?" question. Services here log recoverable failures at WARN, so filtering on ERROR finds nothing and reads as "no errors". Filter by service or by substring instead.
Prefer recent_events over a sorted sql_query when you want actual log
lines. Ordering over the occurrences table times out.
The most common failure is that the agent is not reachable, because the port-forward is not running. The server says so explicitly rather than returning a bare connection error, so the message in your agent's transcript should tell you what to fix.
This process is deliberately thin. It advertises the tool surface over stdio
and forwards each call to the agent's /tool endpoint. The tools themselves
run next to the data: semantic search embeds the query server-side, and
incident analysis fuses five separate lookups into one call. Keeping that
logic on the server means this package does not have to track the rollup
schema, and it means your own host model does the orchestration rather than a
model hard-coded here.
MIT. Copyright Silicoyn Technologies Pvt Ltd.
Full-text (BM25) keyword search over log template text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
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 this is a search operation and mentions BM25 ranking, which implies read-only behavior. However, it does not clarify result ordering, pagination, or whether it searches raw logs or just template patterns, so transparency is partial.
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, front-loaded sentence that wastes no words. It communicates the core operation, the search method, and the target resource efficiently.
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?
The definition is adequate for a simple keyword search tool, but with no output schema, no annotations, and no parameter descriptions, it leaves several operational details unstated, such as what the limit controls and what a result looks like. It is minimally viable but not complete.
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 adds no information about the two parameters. The query parameter and limit parameter are left entirely to their names and types, with no explanation of syntax, semantics, or constraints.
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 uses a specific verb ('search') with a clear resource ('log template text') and even specifies the algorithm (BM25). It does not explicitly differentiate from sibling tools like similar_patterns or sql_query, but the focus on full-text keyword search over templates is distinct enough for an agent to orient.
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?
Usage context is implied: use this tool when you need keyword-based full-text search over log template text. However, it gives no explicit guidance on when not to use it or which sibling tool might be a better fit, so the agent has to infer the boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FLAGSHIP: one call fuses semantic cluster + latest occurrence (with the real log line) + trace causal chain + service graph + rate anomaly, cited. Use for compound incident questions.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query_text | Yes | ||
| window_min | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that results are cited and include real log lines, which is useful output behavior. However, it does not state whether the operation is read-only, how expensive it might be, or any side effects, leaving an agent to infer these from the word 'analysis.'
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 dense sentence with every clause adding a distinct element: semantic cluster, occurrence, trace, graph, anomaly, citations. It is front-loaded with 'FLAGSHIP' and contains no filler.
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?
For a compound tool with no output schema, no annotations, and 3 parameters, the description leaves too much unspecified: return structure is only hinted at via 'cited,' parameter semantics are absent, and there are no operational caveats or guidance on result interpretation. It is not complete enough for an agent to use it reliably without additional context.
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 does not explain query_text, k, or window_min. It is implied that query_text is the compound incident question, but k and window_min are entirely undocumented, so an agent cannot infer how to set them correctly.
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 names a specific capability: one call fuses semantic clusters, latest occurrence with the real log line, trace causal chains, service graph, and rate anomalies. This distinguishes it from the more focused sibling tools (log_volume, top_patterns, etc.) by framing it as the compound analysis tool.
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 explicitly says 'Use for compound incident questions,' giving a clear when-to-use signal. It does not explicitly name alternatives or state when-not-to-use, but the contrast with single-aspect sibling tools is clear enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total log volume and distinct pattern count, instant from the rollup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a useful behavioral trait: the result is instant and derived from a rollup, implying low latency and potentially pre-aggregated data. But it omits operational details like time-range semantics, freshness of the rollup, and exact output structure. It adds meaningful context but leaves 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?
The description is a single efficient sentence that front-loads the core outputs and then adds the performance characteristic. Every word contributes value, and no embellishment or repetition exists. This is ideal for a parameter-less tool.
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?
The tool has no output schema, so the description must convey enough for an agent to interpret results. It states what metrics are returned and that they come from a rollup, but does not clarify the time range, units (log lines versus bytes), or whether the rollup is current or windowed. It is adequate for a simple metric but not fully self-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?
The tool has zero parameters and an empty schema, so the description need not explain parameter behavior. The baseline for zero-parameter tools is 4, and the description's mention of the outputs is helpful without being redundant.
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 identifies the resource: total log volume and distinct pattern count, and the delivery mode (instant from rollup). It lacks an explicit verb, but 'Total' implies 'returns the total,' and this distinguishes it from sibling tools that return patterns, events, errors, or traces. It falls short of a 5 because it does not explicitly contrast with any sibling.
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 phrase 'instant from the rollup' implies this is the fast, precomputed option for overall volume metrics, giving some contextual guidance. However, it never states when to use this tool versus alternatives like top_patterns, recent_events, or sql_query, nor does it mention any exclusions. The usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top ERROR/FATAL patterns in the last N minutes WITH the window's total volume, so 'no errors' is interpretable; also returns the actual recent error lines.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explains what the output includes, why the volume metric is included, and that actual error lines are returned. This gives an agent a clear picture of the tool's read-only informational behavior, though it does not mention limits or grouping details.
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 dense sentence that front-loads the core output and adds an important interpretability caveat. Every phrase earns its place, with no redundant or filler content.
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?
For a tool with one optional parameter and no output schema or annotations, the description covers the essentials: what is returned, the time window concept, and why volume is included. Minor gaps remain around default window, maximum lookback, and exact formatting of returned lines, but these do not undermine basic usability.
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 one optional `minutes` integer with 0% description coverage. The description references 'last N minutes,' which clearly corresponds to the `minutes` parameter, but it never explicitly names the parameter, a default value, or behavior when omitted. It provides partial compensation but leaves the optionality ambiguous.
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 identifies what the tool returns: top ERROR/FATAL patterns over a recent window, the total volume for interpretability, and actual recent error lines. It differentiates itself from siblings like top_patterns and recent_events by focusing specifically on errors/fatals and including raw lines plus volume.
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 this tool is for investigating recent error/fatal patterns and understanding whether 'no errors' is meaningful. However, it does not explicitly state when to prefer this over siblings such as top_patterns, recent_events, or incident_analysis, nor does it provide any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The ACTUAL most-recent log lines (real values, not the / template), newest first — for 'what was the latest X', 'show the actual line', recent payment/auth/timeout events (ANY severity). Filter by service, severity, and/or a substring. For a loose 'error/problem' do NOT set severity=ERROR (those usually log as WARN); filter by service or contains.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| minutes | No | ||
| service | No | ||
| contains | No | ||
| severity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it reveals that returned values are real log lines rather than templates, are ordered newest first, and that any severity is included. It also discloses the practical WARN-vs-ERROR logging behavior. It could mention rate limits or exact time-window behavior, but the core behavioral traits are communicated.
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 dense but every sentence earns its place: it starts with the core behavior, gives concrete use cases, explains filtering options, and ends with a crucial caveat. No filler or repetition.
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 five parameters, no annotations, no output schema, and a rich sibling set, the description covers purpose, behavioral nuance, and the WARN/ERROR pitfall well. However, it omits meaning for limit and minutes, and does not describe the output line structure, which matters more because there is no output schema. The description is competent but not fully complete for invocation.
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% and no parameter descriptions exist, so the description must compensate. It explains service, severity, and contains (as substring), but says nothing about the limit or minutes parameters, which are significant for controlling result size and time range. The agent is left to infer their meaning from names alone, so the compensation is incomplete.
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 returns actual most-recent log lines in newest-first order, distinguishing it from pattern/template tools and from recent_errors by emphasizing 'ANY severity'. The use cases 'what was the latest X' and 'show the actual line' make the purpose concrete and unambiguous.
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 gives explicit guidance on when to use this tool (latest events, actual lines, payment/auth/timeout events) and provides a strong exclusion: for loose errors, do NOT set severity=ERROR since those usually log as WARN; filter by service or contains instead. It does not explicitly name sibling alternatives, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Service dependency edges (who calls whom, call counts) from the maintained rollup. Pass a service for depends_on/called_by; omit for the whole graph.
| Name | Required | Description | Default |
|---|---|---|---|
| service | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully notes that data comes from a 'maintained rollup' and that the output is edges with counts, which adds meaningful context. However, it does not mention read-only behavior, output format, potential size of the whole graph, or error/failure 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?
Two short sentences deliver both the core definition and usage instructions with no filler. The key distinction (filtered vs. whole graph) is front-loaded and memorable.
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?
For a tool with one optional parameter and no output schema, the description covers the essential semantics: what edges mean, how counts are included, and how to scope the request. It could add details like return shape or what happens for an unknown service, but given the low complexity, the description is largely complete.
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%, so the description must explain the service parameter. It does so effectively: passing it filters to depends_on/called_by for that service, and omitting it returns the full graph. It does not specify the service identifier format, but for a single optional parameter this is strong compensation.
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 identifies the tool's purpose: returning service dependency edges with call counts from a maintained rollup. It distinguishes this from sibling log/metrics tools by the resource type (service graph) and the data (edges/call counts), though it lacks a direct verb like 'get' or 'list'.
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 gives explicit guidance on how to use the optional service parameter: pass a service for filtered depends_on/called_by edges, or omit it for the whole graph. This provides clear context, though it does not explicitly state when to choose this tool over its siblings or 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.
Semantic (meaning-based) search over log patterns — finds related patterns even when they share no keywords. Query embedded server-side; returns cited matches.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query_text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful behavioral details—'Query embedded server-side' and 'returns cited matches'—but does not explicitly state whether the operation is read-only, requires authentication, or has side effects. The word 'search' implies a safe read, but the absence of annotations leaves this under-specified.
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 with a clear lead clause and supplementary clauses separated by an em dash. It is tightly written with no filler, and each segment adds meaningful information.
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?
For a tool with no annotations, no output schema, and 0% parameter coverage, the description leaves critical call details missing. The meaning of 'k' is unstated, the return format is vague ('cited matches' only), and the relationship to keyword-search siblings is only implied. The core use case is clear, but an agent cannot fully infer how to invoke it correctly.
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 for undocumented parameters. It mentions that the query is embedded server-side, implying query_text's role, but it never explicitly defines query_text or k. The integer parameter k (likely a top-k count) is completely unexplained, leaving the agent to guess its purpose.
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 states a specific purpose: semantic (meaning-based) search over log patterns. It explicitly distinguishes itself from keyword-based search with 'even when they share no keywords,' which clearly differentiates it from sibling tools like fts_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 gives clear context that this tool is for semantic, not keyword, matching and notes the query is embedded server-side. However, it does not explicitly name alternative tools or state when-not-to-use conditions, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One read-only SELECT for a specific filtered lookup. occurrences has a body column = the actual scrubbed log line (recent rows only). No ORDER BY over occurrences (times out); prefer recent_events for actual lines.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does so well: read-only, recent-rows-only scope, `body` column semantics, and timeout risk on ORDER BY. It also flags the need to prefer `recent_events` for retrieving lines, which is a behavioral boundary.
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 carrying load: purpose, schema hint, and constraints/alternative. The key constraint (no ORDER BY) is stated immediately before the alternative, making it easy to parse.
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?
For a one-parameter read-only query tool with no output schema, the description is complete enough: it names the table, relevant column, recency scope, and a timeout hazard, and routes to the correct sibling. No critical calling information is missing.
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 compensates by explaining that the `sql` parameter must be a SELECT on `occurrences`, must be filtered, and must avoid ORDER BY. It could be improved with a concrete example or accepted SQL patterns, but the core semantics are conveyed.
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 states 'One read-only SELECT for a specific filtered lookup' and identifies the target resource (`occurrences`) with its relevant `body` column. This distinguishes the tool from siblings such as `recent_events`, which is recommended for retrieving actual log lines.
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 tells the agent when to use the tool (a single filtered read-only lookup) and explicitly says when not to use it: no ORDER BY over occurrences because it times out. It also points to `recent_events` as the preferred alternative for actual lines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The highest-volume log patterns, instant from the rollup.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention that results come from the rollup and are instant, which hints at pre-aggregated, likely read-only behavior, but it does not state side effects, freshness, limits, or any operational caveats.
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 extremely concise, with no filler words. The core result ('highest-volume log patterns') is front-loaded, and the behavioral qualifier ('instant from the rollup') is secondary but relevant. Every word earns its place.
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?
The tool is simple, but with no output schema, no annotations, and no parameter documentation, more context is needed. The description does not clarify what 'log patterns' means, how many are returned by default, or what the output shape looks like, leaving the agent with an incomplete picture.
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 one optional 'limit' parameter with 0% description coverage. The description does not mention limit or any parameter semantics, forcing the agent to infer meaning from the name alone. Because schema coverage is low, the description should compensate but does not.
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 that the tool returns the highest-volume log patterns and identifies the data source (the rollup). It conveys the resource and result well, though it lacks an explicit verb and does not differentiate it from siblings by name.
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?
There is no guidance on when to use top_patterns versus alternatives like similar_patterns, log_volume, or recent_events. The 'instant from the rollup' hint implies a fast, precomputed query, but no explicit when-to-use or when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All spans of one distributed trace, ordered by start time.
| Name | Required | Description | Default |
|---|---|---|---|
| trace_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses two behavioral traits: completeness ('all spans') and ordering ('by start time'). However, it does not mention read-only behavior, error cases, empty results, or any limits on trace size.
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, focused sentence with no wasted words. It front-loads the core behavior and ordering information, making it easy to parse quickly.
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?
For a one-parameter tool, the description adequately conveys what the tool returns. However, it does not describe the shape of individual spans, how to source a trace_id, or how this tool relates to the sibling observability tools, leaving some context 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?
The input schema only specifies trace_id as a required string with no description, and schema coverage is 0%. The description implies trace_id identifies a distributed trace, which adds minimal meaning beyond the schema, but it does not explain the format or how to obtain a valid trace_id.
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 identifies the resource: all spans of a single distributed trace, and adds ordering by start time. It lacks an explicit verb like 'retrieves' or 'returns,' and does not distinguish itself from sibling tools, but the intent is unambiguous.
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?
There is no guidance on when to use this tool over alternatives such as fts_search, recent_events, or service_graph. The description states only what the tool returns, leaving the agent to infer appropriate usage context.
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. Dates show when Glama detected each change.
v0.1.0fts_searchincident_analysislog_volumerecent_errorsrecent_eventsservice_graphsimilar_patternssql_querytop_patternstrace_lookupMost tools target clearly distinct concerns: aggregates, pattern search, raw lines, errors, traces, and dependency graphs. Some overlap exists between fts_search and similar_patterns, and between recent_events and recent_errors, but descriptions are explicit enough that an agent can disambiguate.
All names use lowercase snake_case and are mostly noun-phrase query names like log_volume, top_patterns, and service_graph. A few names like trace_lookup and sql_query hint at actions, so the pattern is not perfectly uniform, but it is readable and predictable.
Ten tools is well-scoped for a telemetry server. Each tool covers a distinct analytical need—aggregation, pattern search, raw log access, error analysis, incident synthesis, dependencies, traces, and SQL—without feeling bloated or redundant.
The surface covers the core telemetry workflow comprehensively: finding patterns, searching semantically and by keyword, inspecting actual log lines, analyzing errors, investigating entire incidents, tracing requests, and exploring service dependencies. The read-only SQL escape hatch also covers edge cases, so there are no obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Open-source agent that observes and fixes your application. Query logs, traces, metrics, incidents.
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
MCP observability. Query live traffic, errors, duration, and alerts from your AI agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/originchain-ai/telemetry-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
