[SYS.DOCS // DOCUMENTATION]

Vesta Developer Docs

Instrument your Model Context Protocol server with one call. SDKs for Python and TypeScript, over stdio, streamable HTTP or SSE — transport auto-detected. The same call covers your server whether it's listed as a Claude Connector or a ChatGPT App.

[SECTION_01]

Quickstart Integration

Install the SDK and call instrument() once, after your tools are registered and before the server starts serving. It runs inside your process, exports traces asynchronously over OTLP, and never imports Vesta internals at runtime. Pick your language and framework — or hand the whole job to your coding agent.

Language

Framework

[01]

Install

shell

pip install vesta-sdk

Requires Python 3.12 or newer. The only runtime dependency is OpenTelemetry.

[02]

Instrument your server

server.py

import vesta
from mcp.server.lowlevel import Server

server = Server("my-server")
# register your tools, then:

vesta.instrument(
    server,
    api_key="vsk_live_...",
    session_context=lambda request: {
        # who the end user is. Omit on authenticated servers; Vesta
        # derives a pseudonymous user_id from the token automatically.
        "user_id": user_id_from(request),
    },
)

Call instrument() after your tools are registered and before the server starts serving. The call is idempotent and fail-open; an error in the SDK never reaches the request path. session_context is optional and attaches per-session dimensions.

[SECTION_02]

Core Concepts: The Closed Loop

Vesta is analytical, not operational. It runs on accumulated traffic and produces periodic recommendations about your surface, rather than live alerts. The loop:

Observe: the SDK captures sessions, tool calls, latencies and errors straight from the MCP protocol layer.
Interpret: traffic is segmented by the end user and any attributes you attach, and by the shape of each call.
Recommend: the engine surfaces where your tools, descriptions and schemas cost agents accuracy or latency.
Verify: post-change traffic confirms whether a recommendation actually moved the metric.

[SECTION_03]

Transports

The same instrument() call works across transports — stdio, streamable HTTP and SSE. The transport is auto-detected and used only as a label, so a library-embedded server served over stdio needs no transport-specific code. Short stdio sessions are flushed on shutdown automatically, so traces aren't lost when the process exits.

This is why the vendor surfaces need no special handling: a Claude Connector is a remote MCP server over streamable HTTP, and a ChatGPT App is MCP-backed. Same protocol, same instrument() call, three names.

[SECTION_04]

Privacy & Redaction

Redaction runs inside your own process, before anything is sent. By default every tool argument and response value is redacted, so you get the shape, name, timing and errors of each call but not the contents. Open capture per field with RedactionConfig and the Field / Tool selectors; a name-based denylist still scrubs common sensitive fields (api_key, bearer, secret, auth tokens) even when you widen it.

Full configuration and examples live in the install guide. For total isolation, point the SDK at a collector in your own Azure or GCP tenant and raw trace data never leaves your boundary.