Connector

Limits

Two layers. A per-minute request limit keeps one client from hammering the database. A per-day cap on each write action keeps a looping assistant from creating events or starting cleans without end. Normal use never reaches either.

Requests per minute

Limit: 60 requests per 60 seconds, per operator, across every method
Counted: Every JSON-RPC POST that passes authentication, reads included
Over the limit: HTTP 429, body {"error":"rate_limited"}, a Retry-After header in seconds
Window: Fixed window, best effort per server instance

Back off for the number of seconds in Retry-After and retry. An assistant answering one question makes a handful of calls, so this is a loop guard, not a quota.

Daily write caps

Per operator, rolling 24 hours, counted from the action log so it holds across server instances. The same on every plan. A refused call changes nothing, is logged as daily_limit, and does not count toward the cap.

Action	Calls per 24 hours	Why this number
start_cleaning	30	Clean All is idempotent and only touches uncleaned messages, so repeats are cheap, but a loop would still bill real processing.
create_event	10	Covers a busy operator and caps the clutter of locked events a loop could create.
update_event	50	Renames and date moves are harmless to repeat; the cap exists so a loop is noticed.

What the client receives when a cap is hit, as the text of an isError result:

text

Daily limit reached: your AI assistant has already made 30 cleaning requests in the last 24 hours, so nothing was changed. You can do this in your Happy Hear dashboard now, or ask again tomorrow. If this looks wrong, email hello@happyhearaudio.com.

These numbers were set before any real usage existed and sit far above what one operator does in a day. They are reviewed against the action log; a change is announced on the changelog.

Result sizes

search_events and list_events_needing_attention return at most limit rows (default 25, maximum 100) and flag truncated when they filled it.
Per-event message lists stop at 500 messages.
Each action returns its data once in structuredContent and once as a JSON string in content[0].text, so a response is roughly twice the size of the data.

Timeouts and streaming

Each request has at most 60 seconds of server time. Tool calls answer in well under a second; start_cleaning returns as soon as the work is started, not when it finishes.
The server advertises no list-changed notifications and accepts no subscriptions. A client that opens a listen stream gets an immediate answer, not a held connection.
The tool list is fixed per deployment. Re-run tools/list after a changelog entry, not on a timer.

PreviousActions

NextErrors