# 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:
```json
{"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).