Dataverse MCP Server - create_record tool randomly started failing

(1) Share

Report

Posted on by bszabela3

I have a Copilot Studio Agent built for our CRM. It relies on Dataverse MCP Server to create records across various tables. Things were working great until today - it now is failing to create records, claiming the "item" field needs to be a string, rather than JObject, but the field itself is still calling for (Record). Anyone else run into this before?

Categories:

Model context protocol

I have the same question (0)

All responses (3)

Answers (0)

Sort by

Nivedipa-MSFT Microsoft Employee on at

Like (0)

Report
Copy link

Link copied!
Hello bszabela3,
This looks more like a platform-side issue, not something with your agent.

The error (JObject vs String for “item”) has been showing up recently in cases where create/update operations fail unexpectedly while reads still work. [github.com]

The cause appears to be a serialization/type mismatch in the MCP connector, even though the schema still shows (Record).

This usually points to a recent regression or backend change in MCP/Dataverse integration.

Workarounds (quick):

Re-add the MCP tool to refresh schema

Try sending the payload as stringified JSON

Test it in a new agent/environment

Was this reply helpful? Yes No
Suggested answer

Valantis 6,290 on at

Like (1)

Report
Copy link

Link copied!

Hi @bszabela3,

Confirmed platform regression as Nivedipa-MSFT noted. A few additional things to try while Microsoft works on a fix:

1. Re-add the Dataverse MCP tool in your agent (remove and re-add). This refreshes the schema binding and has resolved the issue temporarily for some users.

2. In your agent instructions, explicitly tell the agent to pass field values as plain strings rather than structured objects when calling create_record. Something like: "When creating records, pass all field values as plain string values, not as objects or JSON structures."

3. If you have a specific table where this is consistently failing, test with a minimal create (only required fields) to isolate whether it's a specific field type causing the serialization mismatch.

4. Check the GitHub issue Nivedipa linked for updates: https://github.com/anthropics/claude-code/issues/66300 the community is tracking fixes there.

If the re-add workaround doesn't help, raise a Microsoft support ticket referencing today's date as the regression start and include the exact error message about JObject vs String.

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No
Suggested answer

Jerald Felix 378 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Hello bszabela3 ,

Greetings! Thanks for raising this question in the Q&A forum.

This is a known platform-level regression in the Dataverse MCP Server, not something caused by your agent configuration. A recent backend change introduced a serialization type mismatch where the create_record tool expects field values as plain strings, but the connector is internally passing them as JObject (a structured JSON object), causing the failure even though the schema still correctly shows the field type as (Record).

Here are the steps you can try right away to get things working again:

Step 1: Re-add the Dataverse MCP Tool
Remove the Dataverse MCP Server connection from your Copilot Studio agent and re-add it. This forces a schema refresh and has temporarily resolved the issue for several users.

Step 2: Update Your Agent Instructions
In your agent's system instructions, add explicit guidance like: "When creating records, pass all field values as plain string values, not as objects or JSON structures." This nudges the agent to format the payload in a way the connector currently accepts.

Step 3: Test With a Minimal Record
If the issue persists on a specific table, try a test create with only the required fields filled in. This helps narrow down whether a particular field type is triggering the serialization mismatch.

Step 4: Raise a Microsoft Support Ticket if Needed
If none of the above workarounds help, open a Microsoft support ticket referencing today's date as the regression start point and include the exact error message ("item field must be a string, not JObject"). This helps Microsoft's team prioritize the fix.

Step 5: Track the Fix
The community is actively tracking this issue. You can monitor updates here: https://github.com/anthropics/claude-code/issues/66300

Microsoft is aware of this regression and a platform-side fix is expected. The workarounds above should help you stay operational in the meantime.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,
Jerald Felix.

Was this reply helpful? Yes No