Power Platform Community Forum Thread Details

Hi,

We are building an agent connected to an internal MCP server that handles search operations. We are encountering two major issues:

1. The agent behaves unintelligently regardless of the LLM used

Even when using more capable models (e.g., GPT‑4.1 or GPT‑5), the agent behaves far less intelligently than expected. Surprisingly, much smaller and simpler models (≈7B parameters) from other providers are able to interact with the MCP server correctly.

Because of this, we suspect the issue is not the LLM itself, but how the Copilot agent interprets or transforms the MCP tool specification.

2. The agent fails to understand or generate fields with `format: date`

We defined the schema below for the stayDates object:

{

  "stayDates": {

    "type": "object",

    "properties": {

      "checkIn": {

        "type": "string",

        "format": "date",

        "description": "Check-in date in ISO format (YYYY-MM-DD)"

      },

      "checkOut": {

        "type": "string",

        "format": "date",

        "description": "Check-out date in ISO format (YYYY-MM-DD)"

      }

    },

    "required": [

      "checkIn",

      "checkOut"

    ],

    "description": "Stay dates info (check-in/check-out in ISO)"

  }

}

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:

 
{

  "checkIn": {

    "$kind": "DateDataValue",

    "value": "2026-06-25T00:00:00.0000000"

  },

  "checkOut": {

    "$kind": "DateDataValue",

    "value": "2026-06-23T00:00:00.0000000"

  }

}

This is not valid according to the MCP schema, and the object structure is incorrect.

We would like guidance on how to:

Ensure Copilot respects the MCP schema, specifically:
- Using "format": "date" properly
- Returning plain ISO strings (e.g., "2026‑06‑25") instead of nested objects
Improve the agent’s reasoning, since its behavior currently seems unintelligent even though the same MCP works correctly with simpler non‑Microsoft LLMs.

Any help or recommendations to improve the agent’s behavior, configuration changes, schema adjustments, or Copilot‑specific considerations.

Thanks

Categories:

Model context protocol

Hi there,

Make the MCP server tolerant to Copilot Studio’s typed date objects + Improve orchestration (“agent seems unintelligent”)

Why this happens

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.

Update your MCP tool input schema to accept either an ISO date string or a typed “data value object”

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):

{

"type": "object",

"properties": {

"stayDates": {

"type": "object",

"properties": {

"checkIn": {

"oneOf": [

{

"type": "string",

"description": "ISO date string in YYYY-MM-DD"

{

"type": "object",

"properties": {

"$kind": { "type": "string" },

"value": {

"type": "string",

"description": "ISO 8601 datetime or date (e.g., 2026-06-25T00:00:00.0000000Z)"

}

"required": ["value"]

}

"description": "Check-in date. Prefer YYYY-MM-DD; may arrive as typed object from Copilot Studio."

"checkOut": {

"oneOf": [

{

"type": "string",

"description": "ISO date string in YYYY-MM-DD"

{

"type": "object",

"properties": {

"$kind": { "type": "string" },

"value": {

"type": "string",

"description": "ISO 8601 datetime or date (e.g., 2026-06-23T00:00:00.0000000Z)"

}

"required": ["value"]

}

"description": "Check-out date. Prefer YYYY-MM-DD; may arrive as typed object from Copilot Studio."

}

"required": ["checkIn", "checkOut"],

"description": "Stay dates info"

}

"required": ["stayDates"]

}

Normalize dates server-side (recommended production behavior)

Implement a small normalization layer in your MCP server:

Normalization rules

If checkIn / checkOut is a string:
- Accept YYYY-MM-DD directly.
- If it’s an ISO datetime (e.g., 2026-06-25T00:00:00...), parse and reduce to date.

If it’s an object with value:
- Parse value as ISO datetime/date.
- Reduce to YYYY-MM-DD.

Validate 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.

4) Fix the “agent seems unintelligent”: focus on orchestration, tool descriptions, and MCP setup

4.1 Strengthen MCP server metadata (name/description) for better tool selection

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):

What the server does (in one sentence)

When to call it (2–3 bullet examples)

Input requirements (including date formatting requirements)

Any constraints (e.g., checkIn must be before checkOut)

This improves tool selection behavior without changing models.

4.2 Add explicit agent instructions for date formatting and tool calling

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):

When calling the MCP tool for stays, always provide checkIn and checkOut.

Dates must be normalized to YYYY-MM-DD before calling the tool.

Do not ask the user for the date format if they provide a recognizable date; convert it internally.

If a date arrives as a typed object (with $kind and value), use the value field and normalize it to YYYY-MM-DD.

This reduces re-prompts and schema drift.

4.3 Confirm MCP prerequisites: generative orchestration must be enabled

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.

4.4 Handle time zones correctly when converting date/time user inputs

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!
Paolo

✅ Did this solve your issue? → Accept as Solution
👍 Partially helpful? → Click "Yes" on "Was this reply helpful?" or drop a Like!

Want more tips on Power Platform & AI? Follow me here:

🔗 LinkedIn: https://www.linkedin.com/in/paoloasnaghi/
▶️ YouTube: https://www.youtube.com/@BeyondThePlatforms
📸 Instagram: https://www.instagram.com/beyond_the_platforms/
🌐 Website: https://www.beyondtheplatforms.com/