When an AI agent is using an MCP server to fetch data, it can sometimes get "loop-happy" and trigger too many SOQL queries, hitting governor limits. Has anyone implemented a caching layer or a specific strategy within the MCP tool definitions to prevent an agent from burning through our daily API or query limits during a long conversation?
3 answers
Governor limits are a huge concern with "agentic" AI. The best practice is to implement "aggregate tools" in your MCP server. Instead of letting the AI call get_record ten times, create a tool like get_account_summary that performs a single optimized SOQL join and returns a JSON blob. Also, you can use Platform Cache (if available in your org) to store common metadata descriptions. This prevents the MCP server from hitting the Tooling API every time the AI asks about the object structure. Lastly, always set a LIMIT clause in your MCP tool's base query logic to prevent the AI from accidentally requesting 50,000 rows.
Are you seeing these limit hits more during the "discovery" phase where the AI is exploring the schema, or during the actual data retrieval? I've found that sometimes the AI tries to "describe" every object in the org, which is an API killer.
You can also monitor this via the "Event Monitoring" logs. It gives you a clear picture of which MCP tools are the most "expensive" in terms of CPU time and query usage.
Exactly, Barbara. And Linda, if you are on a Premium plan, using the "Bulk API 2.0" for the MCP server's background data syncing can save a lot of individual callouts compared to the standard REST approach.
Daniel, it's usually the discovery phase. To fix this, you should strictly limit the "exposed objects" in your External Client App or MCP configuration. Don't just give it "All sObjects" access. If the agent only needs Case and Account data, only expose those. This narrows the AI's focus and prevents it from wandering into unrelated tables, which naturally reduces the number of describe calls and keeps your API consumption lean.