A tool call has two limits: the server may rate limit callers, and the chat app may stop waiting. The MCP tools specification says servers must rate limit tool invocations and clients should implement timeouts. Slow or large security queries can hit either one, so test with realistic sizes before you rely on a connector.
Where the delays come from
- Large results. A project with thousands of findings takes time to assemble and may be paged.
- Heavy operations. Anything that starts a scan or analysis is slower than a lookup.
- Rate limits. The specification lists rate limiting among the things servers must do. A burst of calls, for example from a research run, may be slowed or refused.
- Client timeouts. Clients should time out calls so a stuck tool does not hang the conversation.
What the protocol offers for long work
The architecture overview mentions an optional Tasks extension that lets a server return a durable handle for long running requests, so a client can poll for status and fetch the result later. Whether a particular connector or chat app uses it is a question to ask, not something to assume.
For lists, the specification supports pagination, and tool results can include structured content with a schema, which helps a client handle large outputs.
What it looks like to a user
| Symptom | Likely cause |
|---|---|
| Spinner then an error | Client timeout |
| Fewer results than expected | Pagination, or the model only read the first page |
| Refusal after many questions | Rate limit |
| Works for one project, fails for all | Result too large |
The third row matters for accuracy. An assistant that read page one of five may summarize as if it had everything. Ask it how many results exist, and compare with the product.
A test plan
- Pick your largest project and your smallest.
- Ask the same question of both and time each.
- Ask for a full count, then spot check it.
- Make ten requests in a minute and see what happens.
- Record the results as a baseline for the next release.
Questions for the vendor
- What are the rate limits per user and per tenant?
- How do tools page large results, and how is that shown to the assistant?
- Are long operations asynchronous?
- What does an error look like, and does it tell the assistant what to retry?
The specification distinguishes protocol errors from tool execution errors, and says execution errors should be given to the model so it can adjust and retry. Check the connector returns clear ones.
A caution on automation
Do not work around limits by looping the assistant over every project. That multiplies calls, cost and exposure.
A worked example: the same question on two projects
This is illustrative. A team has a small project with forty findings and a large one with several thousand. They ask the assistant to list critical findings for each.
The small project answers in a few seconds. The assistant reads one page of results, sees the total, and summarizes correctly. The large project takes longer. The connector pages the results. The assistant reads the first page and writes a summary that sounds complete. It is not, because there are more pages.
The team notices only because they compared the count in the answer with the product. They then change how they ask: first, how many critical findings exist in this project, and second, list them page by page until the total is reached. They also ask the vendor to return a clear signal when more results remain.
Step by step: a performance and limit test
- Choose your largest project and your smallest.
- Ask the same three questions of each: a count, a list and a detail lookup.
- Time each answer.
- Check the count against the product.
- Make ten quick requests in a row and record any refusal or slowdown, to find rate limits.
- Ask a question that needs a long operation, such as starting analysis, and see how the connector reports progress.
- Write down which questions are safe in chat and which should go to the product.
Table: symptoms and next steps
| Symptom | Likely cause | Next step |
|---|---|---|
| Error after a long wait | Client timeout | Narrow the question or split it |
| Answer lists fewer items than the count | Paging | Ask for each page, verify the total |
| Refused after rapid questions | Rate limit | Slow down, ask vendor for limits |
| Different results on retry | Data changed or model chose another tool | Check the product |
| Slow only for one tool | Heavy query | Ask the vendor about it |
Why servers rate limit
The specification lists rate limiting among the duties of servers, along with input validation, access control and output sanitizing. It protects the server from overload, and it limits the damage of a runaway assistant or an injected instruction that tries to loop. A buyer should see rate limits as a feature, and should ask what they are.
Why clients time out
Clients should implement timeouts, so that a stuck tool does not leave a conversation hanging. The exact time depends on the app. For slow operations, vendors can use asynchronous patterns. The architecture overview describes an optional extension for long running requests that returns a handle the client can check later. Ask whether your connector uses it.
How to word questions for large data
Ask for counts before lists. Ask for summaries by project, then drill into one. Ask for the data timestamp. Avoid asking for everything in one request, since a model has to hold results in its context, and large dumps crowd out reasoning.
What to put in the contract
State expected limits, support response for timeouts, and notice of limit changes.
Where Safeguard fits
For heavy checks, a standalone scan does not need a chat window. Try the free scan, and consider Safeguard's policies and gates for steps that should run on a schedule rather than in conversation.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow a conversation and notice how the assistant requests data in steps rather than all at once.
Quick check
Who sets the timeout?
Clients should implement timeouts, per the specification. The exact value depends on the chat app.
Can an assistant miss results because of paging?
Yes. If it reads only the first page it may summarize incompletely, so ask for a total and check it.
Should I retry a timed out call many times?
No. Repeated retries increase load and exposure. Narrow the question or move the task to the product.
Sources
Last reviewed: 19 October 2026.
