See also this guide on deploying Coral Server in production
Creating Sessions
The create session endpoint is one of the most important endpoints - it’s how you define and instantiate graphs of agents. While Coral Console has a ready-made interface over this endpoint, when integrating Coral with your application - you’ll want to use this API directly. Every application API call needs one of the server’s auth keys in anAuthorization: Bearer header. Agent secrets do not authenticate these endpoints.
Minimal request body
The body is aSessionRequest. It needs an agentGraphRequest with at least one agent, and a namespaceProvider.
namespace and sessionId. Sessions describes what happens from creation to termination.
Custom Tools
There are a lot of scenarios where agents need to be given capabilities that are tightly integrated with your application. While you can hard code these kinds of tools in agents you write yourself, when using agents from other developers - this doesn’t work. For this reason, Coral Server supports passing custom MCP tools to agents at runtime. When an agent calls one of these custom tools, Coral Server sends a request to an endpoint you provide, to know how to respond.Example - User Input
A common use case in applications is exposing some kind of “chat”-style agent to your end users. This can be implemented using custom tools. One tool can request user input: Coral calls your application endpoint, and the endpoint’s response supplies the user’s answer to the waiting agent. A separate output tool can submit results or display progress. Long-lived user interactions need application storage and timeout handling. As an example, the flow for a user‑input custom tool looks (roughly) like:Callback contract
For an HTTP custom tool, Coral POSTs the tool argument object to your configured URL with/{sessionId}/{agentName} appended. It supplies X-Coral-Namespace, X-Coral-SessionId, and X-Coral-AgentName headers. Verify the X-Coral-Signature header against a lowercase hexadecimal HMAC-SHA256 over the exact request body bytes, using network.customToolSecret. The transport can override the signature header name.
Return HTTP 200 with the tool result. The public server wraps the response body in MCP text content. Other HTTP statuses become tool errors. Custom tool callbacks and end-report webhooks are separate contracts: end reports use network.webhookSecret and the exact configured URL.
Signatures cover the body, not the URL or identity headers. Use a job-specific callback URL, check the expected session and agent against application-owned state, and make result handling idempotent. Store results before returning success. The public server does not provide a durable callback queue or a delivery guarantee.
Complete application example
application.mjs below is a runnable Node.js integration. It starts a callback server, verifies signatures before parsing JSON, creates a deferred session, saves the session-to-user mapping, and then starts execution. A distinct callback URL identifies each job. The example uses an in-memory map; replace it with shared durable storage for a deployed application.
application.mjs
application.mjs
application.mjs