Your request passes through the AI client, MCP DigLab and the connected business service. Each may apply its own limits. A working connection does not remove a service's quotas or your AI application's subscription restrictions.
Rate limits#
Requests can be limited for a particular connection. The managed baseline verified a server-level throttle: requests within the configured allowance succeeded and an excess request returned HTTP 429 with Retry-After.
The allowance used for that test is not a published customer quota. Use the limits in your own handoff. No per-key quota or unlimited-traffic promise should be inferred from this help center.
Timeouts and long operations#
A timeout means that the client did not receive a completed result in time. It does not always mean that the upstream service rejected the action. For reads, narrow the query. For writes, inspect the destination state before retrying.
Large result sets may need smaller date windows, pagination or a more specific filter. Ask for only the fields required by the task so that your AI application can work with the result reliably.
Retry safely#
Respect a returned retry delay. Avoid a rapid loop of identical requests. If throttling persists under normal usage, record the time, tool and approximate request pattern and contact DigLab.
Never retry a send, publish or creation operation blindly. Use a source-system identifier or a supported status check to determine whether it already completed.
Plan for higher usage#
Tell DigLab when you expect a new team, a large import, a bulk workflow or a substantial increase in traffic. Capacity and upstream quotas need to be assessed for that workload; a successful small test is not a load benchmark.