Answered

Making MCP Calls to SharePoint faster

(1) Share

Report

Posted on by Greg Prickril

165

Using MCP to access SharePoint data in Studio Agents. Very slow. By default, it looks through all sites/lists until it finds a good candidate based on name, etc.

I'd like to speed this up by giving MCP a hint. I've tried global variables with site/list ID, using site/list names, and referring to information in Knowledge.

Nothing works. From messages that echo, it seems like it always takes the slowest path possible.

Has anyone successfully improved MCP retrieval performance in SharePoint by making some kind of ID information available?

Categories:

Building Copilot Studio chatbots in Microsoft Teams

I have the same question (0)

All responses (4)

Answers (1)

Sort by

Suggested answer

Ashlesha-MSFT Microsoft Employee on at

Like
a
(0)

Report
Copy link

Link copied!
Hi Greg Prickril

Great question—this is a known performance challenge with MCP's default SharePoint discovery behavior. The exhaustive search you're experiencing is by design, but there are some workarounds and best practices:

Optimization Strategies:

Specify Exact Site/List IDs Upfront

Instead of relying on name-based discovery, pass the full site GUID and list GUID directly in your MCP connector configuration

Example: siteId: "00000000-0000-0000-0000-000000000000" (not just site name)

This bypasses the search phase entirely

Use REST API Directly (Faster)

Consider using Power Automate's HTTP connector with direct SharePoint REST calls instead of MCP for time-critical operations

Example: /_api/web/lists/GetByTitle('YourList')/items

Cache Results in Studio Agents - Store discovered site/list IDs in agent memory/variables after first retrieval

Reuse those IDs in subsequent calls rather than re-discovering

Scope Your MCP Queries

Filter at query time: use MCP parameters to limit scope (e.g., specific site collection URL)

Avoid filtering post-retrieval

Was this reply helpful? Yes No
Suggested answer

Greg Prickril 165 on at

Like
a
(0)

Report
Copy link

Link copied!

I've tried a million ways to manage the IDs. Normally, it simply ignores them. I give explicit instructions to use them.

I've tried having a central topic that sets global variables, I've defined inputs to Child Agents, etc. They simply don't get reliably passed or used.

My biggest discovery is that agents very often ignore their instructions in favor of some pre-baked bias: they try to find a way to update a SharePoint list generically and don't even read the instructions.

BTW, the whole mechanism for passing inputs to Child Agents seems, to put it very mildly, unreliable. Many features I tried seem sloppy.

This stuff is not ready for primetime. Waiting 20 seconds for a single Item to be retrieved via MCP is a non-starter. Unfortunately, I think much of the issue is architectural. Fortunately, if MSFT wants anyone to use this stuff seriously, they're going to have to fix it.

The more deterministic methods you mention aren't really functional equivalents as they aren't as flexible.

Was this reply helpful? Yes No
Verified answer

chiaraalina 2,425 Super User 2026 Season 1 on at

Like
a
(0)

Report
Copy link

Link copied!

HI @Greg Prickril

Have I understood correctly that you already know the site and list IDs/names?

If yes, I wouldn’t use MCP for this. I would use the normal SharePoint connector instead, for example Get items, and set the Site Address and List Name directly in the tool.

MCP is useful when the agent needs to search or explore across SharePoint. But if you already know the exact site and list, that extra discovery step just slows things down.

As far as I know, Copilot Studio doesn’t currently let you override MCP tool descriptions or lock down MCP tool inputs in the same way you can with connector based tools. With connector tools, you can set fixed inputs like Site Address and List Name, which is the control you need here.

I would keep MCP only if you really need broad SharePoint search or Work IQ style discovery. You can also use both in the same agent: connector tools for known lists, MCP for open ended SharePoint exploration.

Was this reply helpful? Yes No
Greg Prickril 165 on at

Like
a
(0)

Report
Copy link

Link copied!

Not a functional equivalent, chiaraalina. Requires much more logic as MCP can convert natural language requests into something executable. I created a Power Automate Agent that takes natural language (prompt) and converts it into structured JSON that a generic Flow can consume (operation, list, columns to update). Haven't touched it in a while. Abandoned it because it was so slow. I'll bet it's faster than MCP though.

MCP is very powerful in terms of returning useful data with very complex queries (sales pipeline updates, for example). Those are worth waiting for. Simply updating status on an Item, not so much. Might experiment with different paths orch can resolve.

Again, root problem is that instructions are ignored. Happens here, Cowork, etc. Highly unreliable.

Was this reply helpful? Yes No