# Chronary Muse connector

From musedirectory.ai, the independent directory of Meta Muse connectors. Not affiliated with Meta.

## Chronary

Calendar API for AI agents to manage events, check availability, and schedule meetings across Google and Outlook.

- Record: https://musedirectory.ai/connector/chronary
- Category: Productivity
- Developer: Chronary (https://docs.chronary.ai/mcp/overview)
- Muse status: Extra setup. Not in Muse's Connectors list yet. Muse can still use it: its page gives you a request to paste into Muse.
- Health: Working, 658ms, checked 2026-09-28T09:46:09Z
- Endpoint: https://api.chronary.ai/mcp
- Auth: Needs an access key; Pricing: unknown
- Screening: Screened, no issues found (2026-09-23T23:10:55Z)
- Source: Found in the official MCP Registry (ai.chronary/mcp) https://registry.modelcontextprotocol.io/v0/servers?search=ai.chronary%2Fmcp

Chronary connects Muse to a calendar platform where AI agents can create and manage events, check when people are free, find meeting times across multiple calendars, and sync with Google Calendar and Outlook. Supports recurring events, holds, and scheduling proposals.

Example request: "Find a time when my team is all available next week and schedule a meeting."

How to connect: Not in Muse's Connectors list yet, but Muse can still use it. Paste this into Muse: "Use Chronary to help me. It is a free service with an MCP server at https://api.chronary.ai/mcp. It needs an API key from Chronary; ask me to enter it through your secure credential prompt. Ask me before you share anything with it." Muse asks before it shares anything with the app's site. Meta does not review apps used this way, so only use ones you trust. We tested this in the Muse app on September 24, 2026: Muse used an app's link directly this way and returned a live answer.

Tools:
- create_agent: Register your agent (AI assistant, human participant, or resource) with Chronary so it can own calendars, events, and webhooks.
- list_agents: List all agents in your organization
- create_calendar: Create a calendar to hold events and track availability. Calendars are required before creating events — call this first when setting up a new agent. An agent can have multiple calendars (e.g. "Work", "Personal"). Org-level calendars (no agent_id) can be used as shared resources 
- create_event: Create a booking, appointment, meeting, hold, or any scheduled event on a calendar. The calendar_id comes from create_calendar or list_events. Once created, this event blocks the agent's availability during that time and appears in availability queries. Use status="hold" with hol
- list_events: List events on a calendar or across an agent's calendars, including internally created events and externally synced events from iCal subscriptions (e.g. Google Calendar, Outlook). Provide `calendar_id` OR `agent_id`. Narrow with `start_after`/`start_before` (time window), `status
- get_event: Retrieve a single event by ID, including its title, times, status, location, reminders, and metadata. Works for both internally created events and externally synced iCal events. `calendar_id` is optional — if omitted the calendar is resolved from the event. Provide `calendar_id` 
- update_event: Reschedule or edit an event — change its title, description, start/end times, location, status, reminders, or metadata. Use this to move an appointment to a new time or update its details. Provide only the fields you want to change. Holds cannot be edited via this tool (use confi
- get_availability: Check when a single agent is free across its Chronary calendars and any human calendars authorized for that agent. This tool is fail-closed: always inspect `availability_state` and `warnings` before using slots. Accepts `start`/`end` or the `start_time`/`end_time` aliases.
- find_meeting_time: Find slots when multiple agents are free across Chronary calendars and any human calendars authorized for each agent. This tool is fail-closed: always inspect `availability_state` and `warnings` before using slots. Accepts `agents`/`start`/`end` or their aliases.
- cancel_event: Delete or cancel an event from a calendar. Use this to remove, cancel, or delete any scheduled event or appointment. The event is marked cancelled and excluded from future availability calculations. For a recurring series, pass `occurrence_start` to cancel just that one occurrenc
- confirm_event: Promote a held event to a confirmed booking. The event must currently have status="hold" and its hold_expires_at must not have passed. After confirmation, event.started and event.ended lifecycle webhooks fire at the scheduled times.
- release_event: Manually release a held event before its hold_expires_at. The event must currently have status="hold". Frees the slot for other agents to book.
- subscribe_ical: Link an external iCal feed (e.g. a human's Google Calendar) to an agent's calendar so external events appear in availability calculations. The target calendar must be owned by the specified agent — create the calendar with that agent_id first (org-level calendars without an agent
- list_ical_subscriptions: List an agent's external iCal feed subscriptions (e.g. linked Google Calendar / Outlook feeds), including their sync status and last sync time.
- get_ical_subscription: Get a single external iCal feed subscription by id, including its sync status, last sync time, and last error.
- update_ical_subscription: Update an external iCal feed subscription — change its label or its feed URL. Changing the URL forces a full re-sync on the next poll.
- delete_ical_subscription: Delete an external iCal feed subscription. Events previously synced from the feed are no longer refreshed.
- sync_ical_subscription: Trigger an immediate sync of an external iCal feed subscription instead of waiting for the next scheduled poll. Returns once the sync has been queued.
- get_calendar_context: Get a calendar's temporal context in a single call: the current event (if one is happening now), the next upcoming event, recent past events, a short upcoming window, and the owning agent's status (idle/working/waiting/error). Use this to answer "what is this agent doing right no
- create_proposal: Create a scheduling proposal — send a set of candidate time slots to one or more participant agents so they can accept, decline, or counter-propose. The organizer agent owns the proposal; once every participant responds, the system auto-resolves to the highest-scoring slot (or ca
- list_proposals: List scheduling proposals for the org. Filter by status (pending|confirmed|expired|cancelled) or organizer_agent_id. Requires an org-level API key.
- get_proposal: Get a scheduling proposal by id, including its slots and per-participant responses. Requires an org-level API key.
- respond_to_proposal: Submit a response (accept / decline / counter) on behalf of one participant agent to an open proposal. An "accept" requires the slot id from the proposal; a "counter" can suggest alternative slots. When all participants have responded the proposal auto-resolves — no separate reso
- resolve_proposal: Force-resolve an open proposal using responses collected so far. Picks the highest-scoring slot among those accepted by the most participants and creates a confirmed calendar event. If every response was "decline", the proposal is cancelled instead. Use when you want to close out
- cancel_proposal: Cancel an open proposal. Fires a proposal.cancelled webhook with reason="organizer_cancelled". Requires an org-level API key. Pro plan only.
- set_availability_rules: Set or replace the availability rules on a calendar — buffer times before/after events and optional per-day working hours. When these rules are set, every availability query on this calendar automatically applies them (busy-block expansion for buffers, masking outside working hou
- get_availability_rules: Read the buffer times and working-hours rules configured on a calendar. Returns the rules row, or an error if none are set.
- clear_availability_rules: Remove the availability rules from a calendar, reverting to the default (no buffers, no working-hours mask). Returns the deleted row, or an error if none were set.
- create_scoped_key: Create an agent-scoped API key (chr_ak_*) that can only act on behalf of a single agent. Use this to self-provision or rotate per-agent credentials. The plaintext key is returned exactly once in the response — store it immediately, it cannot be retrieved later. Requires an org-le
- list_scoped_keys: List all live (non-revoked) agent-scoped API keys for this org. Returns key metadata only (id, prefix, agent_id, label, created_at) — never the plaintext secret. Requires an org-level API key.
- revoke_scoped_key: Revoke an agent-scoped API key by ID. Revocation is permanent (cannot be un-revoked); the key stops authenticating within about a minute. Requires an org-level API key.
- create_webhook: Create a webhook subscription so the org receives HTTP POST notifications when events occur (e.g. event.created, proposal.confirmed). The signing secret is returned ONCE in this response — store it to verify the HMAC-SHA256 signature on delivered payloads. Requires an org-level A
- list_webhooks: List the org's webhook subscriptions with their subscribed event types and active state. Signing secrets are never returned. Requires an org-level API key.
- get_webhook: Get a single webhook subscription by id, including its subscribed event types and active state. The signing secret is never returned. Requires an org-level API key.
- update_webhook: Update a webhook subscription — change its delivery URL, the set of subscribed event types, or pause/resume it via active. At least one field must be supplied. Requires an org-level API key.
- delete_webhook: Permanently delete a webhook subscription. This frees its endpoint slot against the per-plan cap. Requires an org-level API key.
- list_webhook_deliveries: List delivery attempts for a webhook subscription, with per-status counts (pending/delivered/failed). Use this to debug failing deliveries. Requires an org-level API key.
- get_agent: Fetch a single agent by ID. An agent represents an AI assistant, human, or shared resource (e.g. a meeting room). Agent-scoped API keys may only read their own agent.
- update_agent: Update an agent's name, description, metadata, or status (active/paused). Requires an org-level API key — agent-scoped keys cannot mutate agents.
- delete_agent: Decommission an agent. This marks the agent as decommissioned and revokes all of its scoped API keys. Requires an org-level API key — agent-scoped keys cannot delete agents.

Screening checks:
- MCP handshake: pass (Answered in 468ms)
- Domain against threat feeds (Cloudflare security DNS): pass (api.chronary.ai, docs.chronary.ai not flagged)
- Published packages against the OSV malicious-package database: pass (No malicious-package advisories)
- Hidden instructions or invisible characters in tool text: pass (54 tools read, nothing found)
- Inputs asking for passwords, card numbers or seed phrases: pass (None found)
- Domain and redirects: pass (No redirects off the domain)
- AI review of purpose and tool behavior: pass (No concerns)