Limits - Semicola

v3 shares the platform’s transport protections and adds a few bounds of its own. Build for them from the start; they are what keep one slow seller or one large report from stalling everyone else.

MCP bounds

Bound	Limit
One MCP connection	Up to 30 minutes. Deploys may end it sooner.
One tool call	Up to 30 minutes.
Structured response size	Responses over 200 KB are truncated as a safety net. Page with `limit` and `cursor`.
Proposal executions	One running `request_proposals` execution per buyer account.
Each seller in an execution	Bounded to 30 seconds. A seller that does not answer in time is reported as failed or pending.
Delivery ranges	`get_delivery` accepts up to 90 days, or `{ "lifetime": true }`.
Idempotency keys	16 to 255 characters from `A–Z a–z 0–9 _ . : -`. Replays are honored for 24 hours.
Confirmations	A `pending_confirmation` expires after 15 minutes.

REST bounds

Bound	Limit
General requests	100 per minute per key
Authentication routes	40 per 15 minutes
Signup	20 per hour

A limited request gets 429 with RATE_LIMITED, a Retry-After header and RateLimit-* headers.

Designing around them

Do not hold a call open. request_proposals returns straight away with running; follow progress with get or in the Proposals widget instead of waiting on one call.
Keep pages small. Use cursors and bounded limit values, and preserve partial results between pages.
Expect seller latency. Sellers and their inventory systems often dominate response time even when Semicola itself is healthy.
Reuse keys only for true retries. An idempotency key identifies one logical attempt.

Local development builds shorten some bounds so demos stay snappy, for example a two-minute tool call and a 20-second seller window.