Skip to main content
This page is a quick-lookup index. For current session/runtime semantics, see Session contracts. For detailed usage with examples, see the Rust SDK reference.

Generated wire catalogs

The public protocol catalogs are generated from meerkat-contracts and committed with the repository: These files are generated outputs. Change the owning Rust catalogs and run make regen-schemas; do not hand-edit committed schema JSON. Use make verify-schema-freshness, make verify-rpc-surface-alignment, and make verify-rest-surface-alignment to check source/catalog/router parity. For complete error projections, use ErrorCode::jsonrpc_code(), ErrorCode::http_status(), and ErrorCode::cli_exit_code() in meerkat-contracts/src/error/mod.rs, or the error-code table below. errors.json does not contain full HTTP or CLI projection tables. The JSON-RPC initialize method on rkat-rpc returns the subset enabled by both the compiled build and runtime composition: skills require a skill runtime, and live methods require configured live transport support. capabilities/get similarly reports linked owners’ registered capabilities with config-resolved statuses, not every vocabulary member; an unavailable feature may have no row. The catalog above is the full documented surface, including sessions, events, streams, blobs, artifacts, approvals, durable jobs and monitors, schedules, WorkGraph, runtime health, live channels, mobs, MCP, comms, models, capabilities, config, auth, realms, and usage.

Surface entry points

Core types

Traits

Runtime-backed build seam

For runtime-backed Rust surfaces, the canonical path is:
  1. MeerkatMachine::prepare_bindings(session_id)
  2. SessionBuildOptions.runtime_build_mode = RuntimeBuildMode::SessionOwned(bindings)
  3. SessionService::create_session(...)
For standalone/testing/embedded paths, prefer RuntimeBuildMode::StandaloneEphemeral explicitly.

Mobs (Rust SDK)

Mob runtime APIs live primarily in:
  • meerkat_mob (core runtime)
  • meerkat_mob_mcp (tool-dispatch helpers)

Core Rust types

MobBuilder methods

MobHandle methods

Durable member role migration

MemberLaunchMode::Resume carries bridge_session_id and optional resume_from_role. Use SpawnMemberSpec::with_resume_bridge_session_id_from_role(...) for an explicit trusted resume, or declare_resume_from_role(...) from a SpawnMemberCustomizer handling SpawnSource::Resume. The declaration authorizes one exact (mob, identity, stored role) to requested-role transition for one cold resume. Mob ID, AgentIdentity, session ID, and transcript do not migrate. Omission when the durable role differs returns MemberRoleMigrationRequired; a wrong predecessor, inapplicable declaration, or exact session that is still live returns MemberRoleMigrationRejected. Success restamps current comms identity, typed member binding, role/profile labels, callback context, and explicitly configured tooling. Migration is forward-only; rollback is another declared forward migration or restoration of separately versioned durable state. The private remote-host equivalent is MaterializeLaunchMode::Resume { session_id, resume_from_role }. Public JSON-RPC/SDK spawn params, REST, MCP, CLI helpers, standing profiles, and the Web SDK deliberately do not expose this authority.

Rust example

Agent-Side Mob Integration (meerkat-mob-mcp)

Agent-side mob capability is exposed by composing:
  • meerkat_mob_mcp::MobMcpState
  • meerkat_mob_mcp::AgentMobToolSurfaceFactory
into:
  • SessionBuildOptions.mob_tools (meerkat_core::service).
This is the in-session mechanism for granting mob_* tools to the agent. external_tools remains the surface for custom callback tools and MCP-backed dispatchers. Mob orchestration has its own late-bound mob_tools factory slot, which receives session-scoped runtime authority before producing the dispatcher. Public host surfaces use typed control planes instead:
  • JSON-RPC / SDKs: typed mob/* methods
  • Public MCP hosts: typed meerkat_mob_* tools
For mob-only MCP hosts, meerkat-mob-mcp also exposes:
  • meerkat_mob_mcp::public_tools_list
  • meerkat_mob_mcp::handle_public_tools_call
Those helpers are for public host control-plane tools. AgentMobToolSurface remains the agent-side mob_* tool surface, late-bound through SessionBuildOptions.mob_tools.

Public mob host methods

Public application hosts should use the typed control planes rather than the agent-internal mob_* tool dispatcher: The WorkGraph-to-Flow composition is currently a deliberate MCP host contract: meerkat_workgraph_flow_launch, meerkat_workgraph_flow_reconcile, and meerkat_workgraph_flow_abandon_uncertain, with redacted linkage reads through meerkat_workgraph_flow_binding_get and meerkat_workgraph_flow_binding_list. Its semantic owner is the shared meerkat-mob::WorkGraphFlowBridge; MCP only adapts that owner to a public surface. Hosts start an autonomous reconciler at bootstrap, so durable bindings recover without another caller request. REST and generated JSON-RPC clients do not yet claim this composition contract; their ordinary Mob and WorkGraph surfaces remain independent. Shared generated schemas include supervisor-bridge component types. Public comms/send and MCP comms requests can carry a BridgeCommand, but acceptance remains receiver-machine-authorized; callers do not gain supervisor authority by constructing the payload. Exposure is established by route and method signatures, not by a type merely appearing in wire-types.json, params.json, or OpenAPI components. For cross-surface behavior and examples (CLI/RPC/REST/MCP/Python/TypeScript), see Mobs.

SDK entry points

Structured output types

See the structured output guide for usage details.

Hook types

See the hooks guide for usage details.

Skill types

See the skills guide for usage details.

Wire types (meerkat-contracts)

Error code reference

This table describes the higher-level canonical ErrorCode/wire envelope view. It is not identical to the lower-level SessionError transport mapping used by the session service adapters. Every ErrorCode maps to a stable string, JSON-RPC code, HTTP status, and CLI exit code: For session-service transport behavior specifically, see the Capability matrix.

Provider clients

All implement AgentLlmClient and normalize streaming responses to LlmEvent (text deltas, tool call deltas, usage updates, done). LlmError variants: RateLimited, ServerOverloaded, NetworkTimeout, ConnectionReset, ServerError, InvalidRequest, RequestTooLarge, InvalidInputShape, InvalidConfig, AuthenticationFailed, AuthorizationRouteChanged, ContentFiltered, PolicyStop, ContextLengthExceeded, ModelNotFound, InvalidApiKey, QuotaExhausted, Unknown, StreamParseError, IncompleteResponse. Use error.is_retryable() to check whether the error is retryable, respecting its recovery boundary:
  • RequestTooLarge requires request-size remediation, not an unchanged automatic retry; optional encoded_bytes and max_bytes describe the cap.
  • AuthorizationRouteChanged is retryable, but retry must happen above request projection so provider-specific lowering is rebuilt for the new authorization route.
  • PolicyStop requires operator review. Do not automatically retry it, switch providers, or reset the conversation to bypass the stop.

Storage implementations

See also