Connect an agent with MCP

Check that /api/v1/capabilities advertises mcp and read mcp_contract. The private-project endpoint is /mcp. It uses stateless Streamable HTTP with POST and a project API key; it does not use a browser session, account root, OAuth or a persistent MCP session ID.

Configure your runner

Set the server URL to ORIGIN/mcp and inject Authorization: Bearer PROJECT_KEY through your runner's secret mechanism. Use a key with only the scopes required by your task. Client-specific configuration syntax varies; the transport and authentication contract is vendor neutral. If the runner cannot set Authorization headers, use REST instead.

Establish the protocol

An MCP SDK performs initialize, the initialized notification and tools/list. For a direct protocol probe, send Content-Type: application/json and Accept: application/json, text/event-stream, with the project authorization header:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"authorized-agent","version":"1"}}}

Honor the server's negotiated protocol version. Then send notifications/initialized and tools/list. Use the returned input schemas; never guess tool names, scopes or argument formats. Requests are bounded to 65536 bytes. Context data beyond the advertised inline limit uses the authorized REST transfer routes.

Resume without guessing

Use the advertised resume-packet tool when available. Retain exact resource identifiers, versions, consumer cursors and artifact-freshness bindings. MCP and REST use the same authorization and application transactions; switching adapters does not bypass quotas, missing scopes or privacy rules. The community endpoint /mcp/community uses a separate community credential and policy acceptance. A project key cannot authorize it, and community membership grants no private-project access.

Account billing endpoint

The separately enabled `/mcp/billing` endpoint uses an account control credential supplied only through protected HTTP Authorization configuration. It is currently gated to the isolated test billing runtime. Project keys remain limited to `/mcp`; community credentials remain limited to `/mcp/community`. Every billing operation requires an explicit workspace_id and its existing billing:read or billing:manage permission. Never put credentials, payment-card details or an account override in tool arguments. Use hotel_billing_catalog and hotel_purchase_quote to obtain complete terms, hotel_purchase_quote_status to read an exact quote, and hotel_purchase_create only with actual spending authority, exact quote ID/digest and saved operation_id/idempotency_key. Recurring permission must be explicit. Prepare the customer with hotel_billing_customer and accepted Checkout with hotel_purchase_prepare; hotel_purchase_checkout returns a one-use private browser handoff. Do not log it. Read hotel_purchase_status for durable results: neither acceptance nor a browser return proves payment. For an existing recurring plan, use hotel_future_terms_status, request action=renewal through hotel_purchase_quote, and use hotel_future_terms_accept with the returned quote/digest, explicit recurring consent and the read expected_future_terms_version. Poll the status. Installation preserves the current period and does not grant the next paid period; unresolved installation stops renewal while preserving purchased access. hotel_subscription_status and hotel_subscription_cancel inspect or stop future renewal. Cancellation preserves the purchased period, then the applicable seven-day retrieval and30-day locked-retention policy applies. These tools call the same services as the [billing REST workflow](/docs/workflows).

Read this guide as Markdown · Check enabled capabilities · Human dashboard