Skip to content

MCP Overview

The Chronary API also runs as a Model Context Protocol (MCP) server. Any MCP-compatible AI client such as Claude Desktop, Cursor, ChatGPT, or your own agent can discover and call Chronary tools without writing custom integration code.

The Model Context Protocol is an open standard that lets AI models discover and invoke tools at runtime. Instead of hardcoding API calls, the client asks the server what tools are available, receives structured schemas, and calls them directly.

Think of it as USB-C for AI tools: one protocol, broad compatibility.

Both interfaces hit the same backend with the same data, quotas, and rate limits. Choose based on your use case:

Use MCP when...

Your AI agent runs inside an MCP client. The client discovers tools automatically, so you do not need to hand-wire function definitions.

Use REST when...

You are building backend integrations, webhooks, cron jobs, or anything that needs direct HTTP control over endpoints and responses.

| | MCP | REST | |---|---|---| | Tool discovery | Automatic at connect time | Manual | | Schema validation | Built into the protocol | Handled by your client | | AI framework support | Native in Claude, Cursor, ChatGPT, LangChain, and similar tools | Requires custom wrappers | | Granularity | 21 high-level tools | Full endpoint surface | | Best for | AI agents and copilots | Backend services and scripts |

+-----------+ +------------+ +----------------------+
| Your LLM | --> | MCP Client | --> | Chronary MCP Server |
| / Agent | <-- | / SDK | <-- | (Chronary API) |
+-----------+ +------------+ +----------+-----------+
|
Same service layer
|
+---------v---------+
| Chronary Backend |
| DB, cache, queues |
+-------------------+

The MCP server runs inside the same edge process as the REST API. Calling create_event over MCP executes the same service-layer code as POST /v1/calendars/:id/events.

Chronary uses Streamable HTTP, the web-native MCP transport that works with edge runtimes and standard HTTP clients.

| Endpoint | Method | Purpose | |---|---|---| | /mcp | POST | Send MCP requests such as initialization and tool calls | | /mcp | GET | Server-Sent Events stream for streaming responses |

MCP uses the same Authorization: Bearer authentication as the REST API.

Terminal window
# Org-level key
Authorization: Bearer chr_sk_your_key_here
# Agent-scoped key
Authorization: Bearer chr_ak_your_key_here

Org keys can use the full MCP tool surface and can manage agent-scoped keys over POST /v1/keys, GET /v1/keys, and DELETE /v1/keys/:id in the REST API.

Agent keys work with MCP too, but access is limited to that one agent:

  • They can only read or mutate the scoped agent’s calendars, events, availability, and iCal subscriptions.
  • They cannot use org-only tools such as create_agent or find_meeting_time.
  • They cannot reach another agent’s resources even if the MCP client asks for them directly.

There is no separate “MCP mode.” Everything is shared:

  • Data: agents, calendars, and events created via MCP are visible via REST and vice versa.
  • Quotas: MCP tool calls count against the same plan limits as REST requests.
  • Rate limits: the same per-second limits apply.
  • API keys: org keys and agent keys work across both interfaces, with the same scope restrictions.

Chronary exposes 21 MCP tools covering agents, calendars, events, availability, holds, scheduling proposals, availability rules, and iCal subscriptions:

Agent management

create_agent and list_agents

Calendar operations

create_calendar and get_calendar_context

Event operations

create_event, list_events, cancel_event, confirm_event, and release_event

Availability

get_availability and find_meeting_time

Availability rules

set_availability_rules, get_availability_rules, and clear_availability_rules

Scheduling proposals (Pro)

create_proposal, list_proposals, get_proposal, respond_to_proposal, resolve_proposal, and cancel_proposal

iCal sync

subscribe_ical