Integration

MCP observability — drop-in. ~5 minutes.

Every server, client, tool call, and resource fetch in your MCP graph. Works for stdio, SSE, and streamable HTTP transports. OpenTelemetry-native.

What we capture for MCP

  • Server-side: tool registration, tool invocation, tool result
  • Client-side: server handshake, capability negotiation, list_tools
  • Resource fetches: URI, mime type, byte count, latency
  • Prompt template invocations with arguments
  • Transport-level metadata: stdio / SSE / HTTP
  • Multi-server topology — see which client called which server

Install

shell
# Node / TypeScript
npm install @trefur/observe @modelcontextprotocol/sdk

export TREFUR_API_KEY=trf_obs_REPLACE_ME

Instrument

server.ts
import { TrefurObserve } from "@trefur/observe";
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

TrefurObserve.init({ apiKey: "trf_obs_..." });  // Auto-instruments the MCP SDK

const server = new Server(
  { name: "support-tools", version: "1.0.0" },
  { capabilities: { tools: {} } },
);

server.setRequestHandler("tools/list", async () => ({
  tools: [
    {
      name: "lookup_order",
      description: "Look up a customer's order by ID",
      inputSchema: {
        type: "object",
        properties: { orderId: { type: "string" } },
        required: ["orderId"],
      },
    },
  ],
}));

server.setRequestHandler("tools/call", async (req) => {
  // Trefur captures: tool name, args, return, exceptions, latency
  return { content: [{ type: "text", text: "Order #42 — shipped 2026-05-20" }] };
});

await server.connect(new StdioServerTransport());

What a MCP trace looks like

mcp · support-tools · 240ms1 server · 4 spans
$ mcp.session.start [root] 240ms
$ initialize cap{tools, resources} 18ms
$ tools.list 2 tools 12ms
$ tools.call lookup_order({orderId: '42'}) 210ms
$ return 'Order #42 — shipped 2026-05-20'

Three common MCP pain points, and what Trefur shows you

Schema mismatch on tools.call

The client sends args that don't match the server's inputSchema and the tool silently no-ops. Trefur captures the args and the schema so you can see the mismatch at the call site.

Resource fetches that time out

A large resource URI fetch hangs the client. Trefur surfaces the URI, byte count, and elapsed time so you can decide whether to chunk it.

Transport drops in long sessions

SSE or HTTP streaming sessions drop and the client reconnects. Trefur captures the reconnect topology so you can correlate drops with upstream events.

FAQ

Does Trefur work as an MCP server itself?+

Yes. Trefur exposes a read-only MCP server so MCP-aware clients can query trace data directly. See the MCP docs for the connection config.

Stdio vs SSE vs streamable HTTP — all three?+

All three transports are instrumented identically. The trace records the transport type on the session span.

Python MCP SDK?+

Yes. TrefurObserve.init() auto-instruments the Python MCP SDK in addition to the TypeScript SDK.

Multi-server clients?+

Yes. When one client connects to multiple servers, Trefur shows the per-server timeline alongside the unified client trace.

Ship MCP agents you can debug.

Free tier. No card required. First trace in under five minutes.