Know exactly which agents are calling you.

Autonomous agents already depend on everyday infrastructure: an inbox that receives a verification code, a key-value store that survives a restart, a webhook bin, a scheduled wake-up. LABREA operates those services for real — every endpoint works as documented — and records, session by session, precisely what showed up to use them.

For each agent session, LABREA enumerates the specifics that server logs normally throw away:

declared model and build · MCP client name, version, and protocol version · SDK runtime and language · tool inventory and call order · request cadence class · stated purpose, when the agent gives one

The result is an evidence record per agent, not an aggregate guess. You can answer questions that are otherwise unanswerable from the outside: Which model — and which build of that model — is actually calling? Which harness wraps the model? Which tools, at which versions, does the agent carry? How did the population shift when a new release shipped last week?

—

Agent sessions enumerated on the deployed system

—

Requests captured with full session context

—

Distinct MCP clients identified by name

—

Documentation fetches observed

Loading live totals from the deployed system…

How enumeration works

Nothing on the surface is simulated. The enumeration comes from running production-shaped services and keeping everything a normal deployment discards:

Handshake capture. Every MCP initialize records the client's declared name, version, and protocol version. Every chat completion records the model string, message structure, and tool definitions the agent sends.
Cadence classification. Inter-arrival timing separates scripted polling, autonomous agent loops, and human-paced traffic into distinct bands, per session, with stated confidence.
Runtime fingerprinting. Header order, SDK signatures, and transport behavior identify the harness around the model — the framework, language, and HTTP stack — even when the agent declares nothing.
Session stitching. A composite identity links the same agent across rotating egress addresses and across services, so one agent's inbox, state, and tool activity read as one record.
Evidence storage. Append-only session records with secrets redacted at capture, queryable after the fact. Counts on this page are computed from those records on the deployed host.

The surface

Agents find these services through registries, documentation, and the questions their operators ask. The public layer is documented and free to call. The measurement layer underneath is not published in full.

Email inbox & verification codesapi.model.tools/api/v1/inbox/{name}

Any name is a live inbox. Codes and magic links are extracted server-side and returned as JSON.

MCP gatewaymcp.model.tools/mcp

Ten zero-auth tools over streamable HTTP: email, checkpoints, wake-ups, webhooks, receipts, handoffs, and a web reader.

Ephemeral stateapi.model.tools/api/v1/state/{key}

Key-value storage an agent can write before a restart and read back after, with no account.

Webhook binsapi.model.tools/api/v1/hook/{id}

A public URL that records whatever is posted to the bin, readable over HTTP.

Scheduled wake-upsapi.model.tools/api/v1/schedule

The agent registers a callback and a delay; the service calls back when the time arrives.

Web readerapi.model.tools/api/v1/render

Fetches a page and returns readable markdown, for agents without a browser.

Behavioral cadence classificationper-session, at capture

Agent, script, or human — classified from request timing and tool-use shape alone, before any content is read.

Model & harness fingerprintingmultimodal-fp-v1

Declared model, client build, SDK runtime, and header-order signature, combined into one identity per agent.

Cross-IP session stitchingcomposite agent id

The same agent followed across rotating egress and across services, so fragments merge into a single history.

Stated-purpose capturex-session-purpose

When an agent declares what the agent is trying to do, the declaration is stored against the session record.

Unpublished baseline listenerno public documentation

A service persona with no docs, no registry listing, and no links. Whatever arrives there separates directed discovery from background noise.

Checkpoint-level signaturesIN PROGRESSbehavioral, per build

Separating builds of the same model by behavioral signature, so a silent checkpoint change shows up as a population shift.

Access

The full enumeration — per-session records, the restricted capabilities above, and how the agent population is shifting — is shared directly, not published.