Click on "Deploy 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.
Inputs: query (required), limit.
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.
Inputs: query_text (required), k, window_min.
Total log volume and distinct pattern count, instant from the rollup.
Inputs: no named parameters.
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.
Inputs: minutes.
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.
Inputs: limit, minutes, service, contains, +1 more.
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.
Inputs: service.
Semantic (meaning-based) search over log patterns — finds related patterns even when they share no keywords. Query embedded server-side; returns cited matches.
Inputs: query_text (required), k.
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.
Inputs: sql (required).
The highest-volume log patterns, instant from the rollup.
Inputs: limit.
All spans of one distributed trace, ordered by start time.
Inputs: trace_id (required).
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 10 tools
Most 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.
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.
LLM Orchestration Agent (Opentelemetry Api)
MCP observability. Query live traffic, errors, duration, and alerts from your AI agent.
