Copilot Studio and MCP Why your tools don't show up, don't get called, lose data or fail to connect

The short version

We ran MCP vendors' own jobs through Copilot Studio between 23 September and 13 October 2026. As the control, the same models ran the same jobs through Anthropic's and OpenAI's APIs. Copilot failed in eight ways where the control did not. Each failure has a fix on your server, and we tested six of them.

Two vendors have shipped these fixes after our reports. We re-ran the same jobs on the same Copilot agents:

Microsoft keeps a list of known MCP issues for Copilot Studio. On 11 October 2026 it listed five, and none of these eight.

1. MCP tools not showing: Copilot Studio can cut the list at 70

When we added monday.com's MCP server by URL, Copilot Studio kept 70 of its tools and dropped the rest. The only sign was a banner in the tools pane: "Limiting number of tools to 70 — Couldn't retrieve the requested items". The agent never learned that the other tools existed. We saw this from 23 September to 7 October.

The cut is not universal. Another vendor's server with 86 tools, added by URL on 1 October, came through whole, with no banner. We don't know what triggers the limit. If you see the banner, plan for only the first 70 tools to count.

Which 70 depends on order. On 5 October Copilot took tools 1 to 70 of monday's list, in the order the server returned them. On 23 September it had also skipped eight tools that had no title, and it kept four widget tools on top of the 70. By 5 October it no longer did either.

In one release, monday's search tool moved to position 85. GPT-5.5 in Copilot then could not look up the board the usual way. It tried a generic API tool, and Copilot asked the user for that tool's inputs. 0 of 3 runs finished. We put a proxy between Copilot and monday's server and moved search back into the first 70. That alone did not help, because search now required 8 inputs (see 5). With search in the first 70 and one required input, 3 of 3 runs finished. monday then moved search to position 1.

A vendor can also publish a certified connector in Microsoft's catalog. A connector carries a tool list the vendor picked. monday's connector showed 50 of 97 tools in the tools pane on 23 September. It did not include create_item, the tool that creates a single item.

Fix. Count your tools. Put the tools behind your users' main jobs at the top of the list. If you have more than 70, choose which 70 Copilot users get. One way is a second MCP endpoint that lists only those tools.

2. Required fields in array rows: the MCP tool is never called

monday's create_items takes items, an array of rows. Each row must have name and columnValues. We asked agents to turn meeting notes into three tasks. Outside Copilot, Claude and GPT did it 6 of 6 times. Inside Copilot Studio they did it 0 of 24 times, across four models, on the MCP URL and on monday's certified connector (25 to 27 September).

Copilot's own transcripts show the model built a correct call: three rows, each with a name and column values. Copilot recorded the planned call (DynamicPlanStepBindUpdate) and never ran it. There was no error, and monday's server never got the call. Instead, the agent asked the user a question. In 13 of the 24 runs it was this:

What is the name of the item you would like to create?

In the other 11 it was this:

Please provide the column values for the items you want to create. These should be in a JSON string format, specifying the values for each column by their column ID.

Copilot turns an array of objects into its own table type and marks the fields inside each row as required. Its check then treats those fields as missing, even though the model filled them in. Claude Opus 4.8 and GPT-5 Reasoning failed the same way, 0 of 12.

A Microsoft employee replied to our report that it "appears to be a Copilot Studio runtime/schema-binding issue" and escalated it. He called dropping required "a temporary workaround".

Fix. We tested three changes through the proxy, and each one worked 6 of 6 times:

• Keep required off the fields inside each row, and check them in your handler.
• Pass the array as a JSON string.
• Hide the bulk tool, so the model uses the tool that creates one item. Listing both did not help.

monday shipped the first change on 4 October, five days after our GitHub issue (PR #504). On the same agents, Copilot went from 0 of 12 to 9 of 12. The last three failures were causes 1 and 5. After monday's next release on 7 October, 12 of 12.

Arrays without required row fields pass through. A CRM's optional participants array arrived intact, and so did a bulk-create tool whose rows had no required fields.

3. Array rows lose fields: Copilot sends only the first row's keys

Some calls with an array do reach your server, with data missing. Copilot sends every row with only the keys of the first row. A key that the first row lacks disappears from all the others, and no error is shown. We saw it on four servers between 1 and 8 October.

• Lucid's org-chart tool lost managerId from all seven people. The person at the top comes first and has no manager. The server created no chart.
• In an opening-hours tool, 15 of 15 writes left a day without the one property it needed.
• A CRM created an empty task, and the agent told the user the task was created.
• An update tool lost a field from the second of two actions in one call.

Fix. Give every row the same keys. Use an empty value where a row has nothing, such as managerId: "" for the person at the top. With that change the org chart went from 0 of 3 to 3 of 3. Lucid shipped it on 12 October, six days after our GitHub issue. Its schema now says "Include managerId on every node". On 13 October the same Copilot agents made the chart 6 of 6 times, through Lucid's connector and through the URL. On the update tool, a tool description that asked for one action per call went from 0 of 3 to 3 of 3. Where rows differ by nature, such as open and closed days, giving every row both keys did not work in our test. We reported the bug to Microsoft (report).

4. "Error code: SystemError": array items without a type

The same org-chart tool first declared its rows as "items": {}, with no type. Copilot read that as an array of plain values. When the model passed objects, Copilot stopped before calling the tool, and the user saw this:

Sorry, something unexpected happened… Error code: SystemError

The transcripts show the model's arguments were correct: seven people with their roles and managers. The step finished as failed in zero seconds, and nothing reached the server. Outside Copilot, Claude and GPT finished the job 6 of 6 times with one call. In Copilot it finished 0 of 6 times, on Lucid's own connector and on the URL (1 October).

Fix. Describe each row as an object with its properties, for example "items": {"type": "object", "properties": {…}}. With typed rows the call reached the server, but the user still saw SystemError, 0 of 3. The job passed only when every row also carried the same keys (fix 3): 3 of 3. Lucid's release on 12 October does both, and Copilot then made the chart 6 of 6 times.

5. Copilot asks the user for an input the model left out

Anthropic's and OpenAI's clients pass a server's "invalid arguments" error back to the model, and the model tries again. Copilot checks required inputs itself. When one is missing, it asks the user and uses the input's description as the question.

In one of three runs on a forms tool (25 September), GPT left out a required search input. Copilot asked the user to supply it, in the words of the input's description. On 5 October monday's generic API tool required a variables input. When the model skipped it, Copilot asked the user for that too.

Fix. Require only what you cannot default. monday now defaults variables to {}. In our test that default took the job from 0 of 3 to 2 of 3. The third run asked the user for the board ID. Keeping search in the first 70 with one required input went 3 of 3 (see 1).

6. "GetDynamicClientRegistrationResultAsync failed": Microsoft's redirect URI is refused

To sign in with OAuth, Copilot Studio registers itself as a client of your authorization server, through dynamic client registration (DCR). Its redirect URI is on global.consent.azure-apim.net. On 23 September a CRM vendor's authorization server refused it:

Failed to login. GetDynamicClientRegistrationResultAsync failed. Status Code: BadRequest, Response: {"error":"invalid_redirect_uri","error_description":"Invalid redirect URI"}

We registered test clients with the same server. It accepted redirect URIs for Claude, ChatGPT and localhost. It refused both forms of Microsoft's URI, and any other https site. So it was an allowlist, and Microsoft was not on it. On that day no Copilot user could connect by the vendor's documented OAuth path. An undocumented API key header worked and gave the full tool list.

Fix. Allow Microsoft's redirect URIs: https://global.consent.azure-apim.net/redirect, and the per-connector form, which is that address followed by / and the connector's ID. We could not see the exact URI Power Platform sent, so we could not test this fix end to end.

7. "Could not discover authorization server metadata"

This is the full error: "Failed to login. Could not discover authorization server metadata." On 8 October we put a pass-through proxy in front of another vendor's MCP server and logged what Copilot asked for:

• A GET on the MCP URL with no token. The server answered 403, because it sent its 401 challenge only to POST.
• The protected-resource document in the path form only: /.well-known/oauth-protected-resource/<path>. Copilot never asked for the root form, which was the one the server had.
• The authorization server's metadata on the MCP host: /.well-known/oauth-authorization-server, with and without the path.
• /.well-known/openid-configuration, in two forms.

The four other servers we checked served both documents on the MCP host, even when their authorization server ran elsewhere.

Fix. On the MCP host, serve the path-form protected-resource document and a copy of your authorization server's metadata. Answer 404, not 403, for other unknown well-known paths. The 403 on GET did not need to change. Through the proxy, that was enough. Copilot registered, the user signed in, and the connection turned green.

8. 401 when loading tools after OAuth sign-in

With sign-in fixed, loading the tools failed with 401 (8 October). Copilot asks for tokens without a resource parameter (RFC 8707). So the token's audience is the authorization server's default, not your MCP server. We saw this in the token claims. It did not change when the protected-resource document named the resource. Another developer reported the same on Microsoft Q&A.

Fix. When a client sends no resource, have your authorization server issue tokens for your MCP server. Accepting the default audience instead is risky if other tokens share it. We could not test this part from outside.

Reproduce these failures in Copilot Studio

• Turn on generative orchestration. MCP tools need it.
• Test the MCP URL and your certified connector, if you have one. They give the agent different tool lists.
• Read Copilot's transcripts in Dataverse, in the conversationtranscripts table. DynamicPlanStepBindUpdate holds the call the model planned. A DynamicPlanStepFinished that completed means the call ran. No finish, or a failed finish in zero seconds, means Copilot stopped the call.
• After you publish an agent, wait. In our tests a publish took more than four minutes to reach Direct Line, the API we sent test messages through. Runs in that window used the old agent.

How we tested

• Copilot Studio in our own tenant: a Copilot Business trial, a pay-as-you-go sandbox environment, Standard agents (what Microsoft calls the standard harness), generative orchestration and no agent instructions.
• Models inside Copilot: Claude Sonnet 4.6 and GPT-5.5 Chat, the Studio default when we created the agents in September. For the monday job also Claude Opus 4.8 and GPT-5 Reasoning, on 27 September. Newer models are untested.
• Controls outside Copilot: Claude Sonnet 4.6 through Anthropic's MCP connector, and GPT-5.5 through OpenAI's hosted MCP tool.
• Vendors' public MCP servers, trial accounts and made-up data. Each job ran three times per setup. We checked the result through the vendor's own API.
• Fix tests used a pass-through proxy that changed one thing at a time.
• Dates: 23 September to 13 October 2026. Copilot Studio changes often. One rule we saw on 23 September was gone by 5 October.
• Limits: one tenant. Three runs per setup show that a failure repeats. They do not rank vendors.

Questions

Why are some MCP tools not showing in Copilot Studio?

On some servers Copilot Studio keeps only the first 70 tools and shows the banner "Limiting number of tools to 70". We saw it on monday.com's server from 23 September to 7 October 2026. Another vendor's server with 86 tools came through whole. Put the tools your users need first in your list.

Why does Copilot Studio ask for "column values as a JSON string"?

Your tool takes an array of rows with required fields. Copilot treats those fields as missing even when the model filled them in, and asks the user. Make the fields inside each row optional and check them in your server. In our tests that took the job from 0 of 6 to 6 of 6.

Does a stronger model fix the required-fields problem?

No. On 27 September, Claude Opus 4.8 and GPT-5 Reasoning failed the same monday.com job as the default models, 0 of 12. Outside Copilot, Claude and GPT finished it 6 of 6. Copilot's transcripts showed correct calls that Copilot never ran. Newer models are untested.

Why does an MCP tool fail with "Error code: SystemError" in Copilot Studio?

The tool probably takes an array whose items have no type ("items": {}). Copilot reads it as a list of plain values and stops before calling the tool when the model passes objects. Describe each row as an object, and give every row the same keys. Lucid made both changes on 12 October, and its org-chart job went from 0 of 6 to 6 of 6 in Copilot.

Has any vendor fixed these problems?

Yes. monday.com fixed required fields in array rows and its tool order after our reports in September and October 2026: on the same agents Copilot went from 0 of 12 to 12 of 12. Lucid fixed its org-chart rows six days after our report: 0 of 6 to 6 of 6.

Why does Copilot Studio fail to sign in to my MCP server?

We saw three causes. "GetDynamicClientRegistrationResultAsync failed" means your OAuth server refused Microsoft's redirect URI. "Could not discover authorization server metadata" means Copilot did not find your OAuth documents on the MCP host. A 401 after sign-in means Copilot asked for a token without a resource parameter.

Should Copilot users connect through my certified connector or the MCP URL?

Test both. A certified connector carries the tool list you picked. The URL path gets your tools in server order, and on some servers only the first 70. In our monday tests the connector listed about 50 tools and the URL path 70 to 74.