You’re offline. This is a read only version of the page.
Hi,
We are building an agent connected to an internal MCP server that handles search operations. We are encountering two major issues:
Because of this, we suspect the issue is not the LLM itself, but how the Copilot agent interprets or transforms the MCP tool specification.
Share
Reportformat: datestayDates object:The agent is unable to correctly populate these fields.
Instead, it repeatedly asks the user for the date format and then outputs an incorrect structure, for example:
This is not valid according to the MCP schema, and the object structure is incorrect.
We would like guidance on how to:"format": "date" properly"2026‑06‑25") instead of nested objectsAny help or recommendations to improve the agent’s behavior, configuration changes, schema adjustments, or Copilot‑specific considerations.
Thanks
When Copilot Studio calls an MCP tool, parameters may be serialized through Power Platform’s connector/runtime layer, which can represent date/datetime values as typed objects (for example objects containing $kind and value) rather than plain ISO date strings—even if your MCP JSON Schema says "type": "string", "format": "date".
Because "format": "date" is an annotation and not always enforced as a strict serialization constraint across runtimes, you should accept multiple shapes and normalize server-side for reliability.
Instead of requiring only "type": "string", "format": "date", define oneOf so your server can safely handle both forms and remain compatible with Copilot Studio’s runtime behavior.
Example schema (for stayDates):
Implement a small normalization layer in your MCP server:
Normalization rules
All responses (
Answers (
237
checkIn / checkOut is a string:
YYYY-MM-DD directly.2026-06-25T00:00:00...), parse and reduce to date.value:
value as ISO datetime/date.YYYY-MM-DD.checkIn <= checkOut after normalization and return a clear error if not.This makes your server resilient to platform-specific typed representations while still returning/using a stable canonical date format.
Copilot Studio’s MCP onboarding flow explicitly states that the Server description is used by the agent orchestrator to decide whether and when to call your server. If the description is vague, the agent may call it incorrectly or fail to gather the right inputs.
Recommended description pattern (copy‑paste template):
This improves tool selection behavior without changing models.
Copilot Studio provides first-class guidance for controlling structured outputs and maintaining stable formats (e.g., when using JSON output, the platform emphasizes keeping formats consistent and “locked” for runtime use). Apply the same principle to tool calling: explicitly instruct the agent how to supply parameters, especially dates.
Example instruction block (copy‑paste):
checkIn and checkOut.YYYY-MM-DD before calling the tool.$kind and value), use the value field and normalize it to YYYY-MM-DD.This reduces re-prompts and schema drift.
Microsoft’s announcement of MCP in Copilot Studio notes that generative orchestration must be enabled to use MCP. If it’s not properly enabled/configured, tool calling quality can degrade or behave unexpectedly.
Copilot Studio stores date/time in UTC and provides guidance on managing the user’s time zone and offsets. If you convert datetimes to dates, ensure you apply the correct time zone logic to avoid off-by-one-day errors.
Hope this helps!
