Get startedQuickstart

Quickstart

Connect your workspace, issue a scoped runtime credential, start one agent, and verify the complete LiveProbe path.

LiveProbe lets an AI client, connected over MCP (the Model Context Protocol), attach short-lived, read-only probes to a service you already have running in Node.js, Python, the JVM, Rust, or C++ — then read back real captured values, log lines, execution counts, or metrics from it. Nothing is redeployed and no probe ever calls, assigns, or otherwise executes your code. There is no separate LiveProbe dashboard: every action below, from creating a project to reading evidence back, is one of the tools in the MCP tool reference, run by asking your connected AI client to call it. See How LiveProbe works for the full request path and what a probe can and cannot do.

Before you start

You need a Clerk account with an active organization. Signing in through the hosted MCP connection below handles this: sign up or sign in when prompted, and create an organization there if you don't already belong to one. If your team already has a LiveProbe workspace, join that organization instead of creating a new one.

You also need an MCP client that supports remote servers over Streamable HTTP with OAuth — this guide uses Cursor as the worked example, see Connect MCP clients for other clients and the local stdio fallback — and access to the deployment configuration for the service you want to observe. Runtime agents support Node.js 20+, Python 3.12+, and Java 17+. Rust and C++ use the host-level eBPF agent instead, with no library added to your build.

Deploying into Kubernetes rather than onto a host or VM? Follow Deploy on Kubernetes — the native agent becomes a per-node DaemonSet, executable paths refer to the container rather than the node, and granting the agent its one capability takes a step that fails silently if you miss it.

Use the deployed revision

Every runtime agent refuses to start without a concrete hexadecimal commit SHA. Supply the revision that built the deployed process, not an arbitrary local checkout.

Connect the hosted MCP server

Add the production endpoint to Cursor or another OAuth MCP client:

json
{
  "mcpServers": {
    "liveprobe": {
      "url": "https://liveprobe.tryastrea.tech/mcp"
    }
  }
}

Choose Login, sign in through Clerk, and select or create an organization. No shared API key or local npm package is needed for hosted MCP access.

Create a runtime identity

Ask the connected LiveProbe MCP server to perform these steps:

  1. Create a projectUse one stable ID for the repository or application, such as acme.
  2. Create an environmentAdd a deployment target such as staging or production.
  3. Register a serviceUse one stable service ID for each independently deployed process, such as api or worker.
  4. Create a service credentialThe plaintext lp_service_... key is returned once. Place it directly in the deployment secret manager.
text
Create project "acme", add its "production" environment,
register service "api", and create a production service credential
labeled "Acme API production".

Start one runtime agent

Configure the same project, environment, service, credential, and deployed commit in the application. Follow the exact startup steps for your runtime: Node.js, Python, JVM, Rust, or C++.

dotenv
LIVEPROBE_BROKER_URL=https://liveprobe.tryastrea.tech
LIVEPROBE_PROJECT_ID=acme
LIVEPROBE_ENVIRONMENT=production
LIVEPROBE_SERVICE_ID=api
LIVEPROBE_API_KEY=lp_service_<shown-once-secret>
LIVEPROBE_COMMIT_SHA=<deployed-git-sha>

Deploy the agent with the application. The application does not need to run on GCP; it only needs outbound HTTPS access to liveprobe.tryastrea.tech.

Verify the connection

Run these read-only tools before placing a probe:

text
Ping the LiveProbe broker. In project acme and environment
production, list online services and show the safety overview.
Do not create a probe yet.

list_services should show the service ID, SDK, deployed commit, latest heartbeat, capabilities, and online state. An empty list means the agent has not successfully heartbeated in the selected project and environment.

get_safety_overview reports whether LiveProbe's own instrumentation is running within its limits for that service — see Runtime safety for what each state means.