REST for the catalog, webhooks for change events, A2A for agent-to-agent discovery, MCP for tools — all behind the same RBAC, rate limits, and audit trail.
Four interfaces onto the same catalog — pick the one that matches how your system already integrates.
Interface
What it Does
Catalog API (rest)
OpenAPI 3.0-documented REST API, polled or queried, for agents, tools, and knowledge bases
Webhooks
Real-time push on catalog lifecycle events — tool deprecated, knowledge base created or updated, agent version promoted
A2A Agent Cards
Every registered agent auto-exposes capabilities and I/O schemas, so other agents can discover and call it
OpenAPI Export
Every catalog entry exposes an OpenAPI definition that drops straight into your existing API catalog infrastructure
WebSocket (conversation-chat)
Session-based conversational endpoint with checkpointed state — survives disconnects and resumes where it left off
Recommended integration pattern: webhook for real-time sync, REST poll for reconciliation. All sync operations are audit-logged and RBAC-scoped.
LLM choice is config, not code — and so is your identity provider.
Session Auth
HTTPBearer scheme with JWT verification; session data cached in Redis with a database fallback for durability.
Service Auth
Keys carry explicit scopes (e.g. tools:execute) and a project ID — a key can only act where it's been granted access.
Identity Federation
Azure Service Principal, AWS IAM Role, GCP Service Account, Databricks PAT, OAuth 2.0, Bearer, API Key, custom headers, and more.
Service-to-service calls run through a dedicated Integration Bot role — a narrow API subset and scoped keys, using the same CAN_{ACTION}_{RESOURCE} permission vocabulary as every other role.
MCP is the protocol. What matters is what governs the server.
Speaks JSON-RPC 2.0 over Streamable HTTP, with a tools:execute scope and an Mcp-Session-Id lifecycle. Every tool gets its own vault-backed credential through identity federation — no shared service accounts.
Script tools run with a trimmed __builtins__; HTTP tools are isolated, with no persistent connections shared across tools. Rate limiting is enforced per-tool, per-project, on an execute:{project_id}:{api_key_id} key pattern.
Isolated requests via httpx; cannot reach other tools' endpoints or credentials.
Language-level restriction on a trimmed builtin set, with unbounded usage prevented by rate limiting.
Register an external server's endpoint as a tool in the catalog — the same controls apply, including mutual TLS or API key exchange.
Because we've answered them before.
The Catalog API and Orchestration Schema are versioned (schema currently v13). Platform releases follow versioned, auditable release management — breaking changes are never silent.
Workflow state is checkpointed to Redis (with PostgreSQL durability as an option) at each execution step. On reconnection, the client resumes from the last checkpoint using the session ID.
Yes — register the endpoint in the Tool Catalog. Authentication, rate limiting, and audit logging apply exactly as they do to our own tools.
Yes — Kong, Azure APIM, AWS API Gateway, and Apigee are all supported in front of the platform's API surface for additional authentication, rate limiting, or policy enforcement.
We'll provision a sandbox tenant with the Catalog API, webhooks, and a starter MCP tool already wired.
Book a Demo
Or drop us a line at [email protected]
