PowerLeap Logo

Copilot Studio Friction

Get notified when this record changes

One email when the status or the fix changes — double opt-in, no tracking, unsubscribe in every email.

Users see raw {"explanation_of_tool_call": …} JSON — only in production

Mitigatedsince 8 July 2026

Last verified

Details & related

Assessment

Confidence
CorroboratedMultiple independent sources describe the same behaviour.
Severity
Degrading
Typical time lost
Hours

Identification

LLM stepsOrchestrationMicrosoft TeamsM365 Copilot Chat

Verification & changes

  1. Change

    Pipeline: new evidence from r-copilotstudio — review required.

  2. Change

    Pipeline: new evidence from r-copilotstudio — review required.

  3. Verified

    Doc check by human: Bounded web check: further independent Q&A threads report the same production-only leak, but no public Microsoft known-issue or release-note entry exists; the product-issue acknowledgment remains a thread claim.

  4. Change

    Provisionally approved by the Product Owner; external LLM quality review pending.

Show 1 older entries

  1. Change

    Initial record created from the seed dossier (migration wave 1).

Related

Are you in the right place?

  • End users see JSON like {"explanation_of_tool_call": "The user has requested…", "type": "…"} instead of an answer.
  • It happens only in the published agent — never in the test pane.
  • The tool often runs only after the user pushes with something like "go ahead then".
  • JSON fragments also appear after correct answers, or in the default "Thanks" topic.
  • The behavior started around October 2025, without any change on your side.

If your own tool output shows unparsed → see Chat shows raw JSON instead of an answer. That record covers unparsed connector, HTTP, or flow output anywhere, including the test pane. This record covers the platform's internal tool-call metadata, in production only.

What's happening

When your agent decides to call a tool, the orchestrator writes an internal plan first. That plan is a JSON object with fields like explanation_of_tool_call. Community reports tie the leak to the October 2025 platform update, which changed tool-call parsing (reported as of 2026-07-08). Since then, published agents sometimes send that plan to the user instead of executing it. Later topics can inherit the whole tool object and leak it again. It's like a waiter bringing the kitchen's order slip to your table instead of the dish. One thread answer calls this a known internal product issue. No public Microsoft statement confirms that claim (checked as of 2026-07-08).

For technicians

Multiple independent Q&A threads describe the same symptom set. Metadata JSON appears instead of the tool call, execution needs a follow-up nudge, and fragments trail correct answers. The default "Thanks" topic inherits the tool-metadata object and re-leaks it. All reports agree: production only, the test pane stays clean. The thread mitigation stores only the readable text per topic.

dialog.topicResponse = toolResult.responseText

The message node then references that text variable, so later topics never inherit the metadata object. As of 2026-07-08, Microsoft's public known-issue and release-note pages carry no entry for this behavior.

How to fix it

Solution 1

Community workaround

Store only the tool's text answer, per topic

This is the variable hygiene pattern applied to tool calls.

  1. Open the topic that calls the tool.
  2. After the tool node, add a "Set a variable value" node.
  3. Create a new variable, for example topicResponse.
  4. Set its value to the tool result's responseText property, as in the snippet above.
  5. Point your "Send a message" node at that text variable, not at the tool output object.
  6. Repeat steps 1–5 for every topic that sends tool output to users.
  7. Publish the agent.

✅ You should now see: plain text answers in the published agent, with no JSON wrapper.

Check that it worked

Trigger the tool in the published channel — Teams or Microsoft 365 Copilot Chat — not in the test pane. Expected: the tool runs on the first request and answers in plain language. Also send a quick "thanks" afterwards: the reply must stay free of JSON fragments.

If it didn't work

  • Your fix has not propagated yet. Published changes reach channels asynchronously — suspect number one. See Teams answers with an old version of your agent.
  • One topic still forwards the whole object. A single unhygienic topic reinfects the conversation. Sweep every topic that touches tool output.
  • The JSON is your own tool's output, unparsed. Then you are in the wrong record. See Chat shows raw JSON instead of an answer.
  • The platform shifted again. The leak arrived with a platform update and may change with the next one. Retest after updates and note the date.

Prevent it next time

  • Make variable hygiene a habit: never pass whole tool objects to message nodes or between topics.
  • After every platform update, retest tool-calling topics in a published channel, not only in the test pane.

Evidence

  • Community threadlearn.microsoft.com

    Several users in one thread report raw explanation_of_tool_call JSON reaching end users in production since the October 2025 update, mitigated by storing only responseText in a variable.

  • Community threadlearn.microsoft.com

    An independent thread reports the orchestrator displaying explanation_of_tool_call and new_instruction metadata to end users.

  • Community threadreddit.com

    User reports citations appearing as non-clickable code after MCP Server integration, matching the raw JSON visibility symptom when tools are called in production.

  • Community threadreddit.com

    Raw JSON rendering in chat and UI panels instead of formatted citations/clickable links extends the existing explanation_of_tool_call JSON visibility bug to MCP connectors and citation contexts.