MCP tools with $defs/$ref in inputSchema fail — parameters can't be constructed

[octosteve]

MCP tools with $defs/$ref in inputSchema fail — parameters can't be constructed

Describe the bug

MCP tool calls fail with Input validation error: 'X' is a required property when the MCP server's tool inputSchema uses $defs + $ref to define parameter types. The $ref references are never resolved, so the client cannot construct or validate the required parameters.

Tools that don't use $ref (e.g., simple tools with no required params) work fine on the same MCP connection.

Affected version

0.0.423

Root cause analysis

The PagerDuty MCP server (https://mcp.pagerduty.com/mcp) returns tool schemas like this (abbreviated):

{
  "name": "list_schedules",
  "inputSchema": {
    "$defs": {
      "ScheduleQuery": {
        "properties": {
          "query": { "type": "string", "default": null },
          "team_ids": { "type": "array", "default": null },
          "limit": { "type": "integer", "default": 20 }
        },
        "type": "object"
      }
    },
    "properties": {
      "query_model": { "$ref": "#/$defs/ScheduleQuery" }
    },
    "required": ["query_model"],
    "type": "object"
  }
}

This is valid JSON Schema. The $defs block is present in the same schema object and $ref points to it. However, the Copilot CLI MCP client:

1. Presents the tool parameter as just "query_model": {"$ref": "#/$defs/ScheduleQuery"} — the reference is never inlined
2. The model has no visibility into the actual properties of query_model
3. Every call fails validation because query_model is required but the model can't construct it

Steps to reproduce

1. Configure the PagerDuty MCP server:

{
  "pagerduty": {
    "url": "https://mcp.pagerduty.com/mcp",
    "type": "http",
    "headers": {
      "Authorization": "Token token=${PAGERDUTY_API_TOKEN}"
    }
  }
}

2. Start copilot
3. Ask: "Who is on call?"
4. The agent attempts to call list_schedules or list_oncalls
5. Every call fails with: MCP server 'pagerduty': Input validation error: 'query_model' is a required property

What works vs. what doesn't

Tool	Has $ref?	Result
get_user_data	No (no params)	✅ Works
get_incident	No (incident_id is a plain string)	✅ Works
list_schedules	Yes (query_model: $ref ScheduleQuery)	❌ Fails
list_oncalls	Yes (query_model: $ref OncallQuery)	❌ Fails
list_incidents	Yes (query_model: $ref IncidentQuery)	❌ Fails

Expected behavior

The MCP client should resolve $ref references within inputSchema (at minimum local $defs references) before presenting tool parameters to the model, so it can construct valid inputs.

Additional context

• The PagerDuty server's schemas are valid JSON Schema and work correctly when called via curl
• This likely affects any MCP server that uses $defs/$ref in inputSchema (a common pattern in Python MCP servers using Pydantic models)
• Related: Empty Input Schema Breaks Copilot CLI #1825 (another inputSchema handling issue)

[austindrenski]

I'm encountering a similar issue, but with a quirk that sometimes the first tool call works.

MCP server '...': validating "arguments": validating root: validating /properties/filter: validating /$defs/filter: type: {"$and": [{"entity": {"$eq": "..."}}]} has type "string", want "object"

So, expected args should look something like this (i.e., S3 Vectors filter syntax):

{
  "filter": { "entity": { "$eq": "..." } },
  "query": "..."
}

But Copilot seems to instead send:

{
  "filter": "{ \"entity\": { \"$eq\": \"...\" } }",
  "query": "..."
}

The input schema is along the lines of:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$defs": {
    "filter": {
      "properties": {
        ...
      },
      "type": "object"
    },
    ...
  },
  "properties": {
    "filter": {
      "$ref": "#/$defs/filter"
    },
    "query": {
      "type": "string"
    }
  },
  "required": [
    "filter",
    "query"
  ],
  "type": "object"
}

In practice, #/$defs/filter has a long set of properties that themselves are defined in terms of other, self-referential schemas defined in #/$defs/..., so not something we can properly represent without working support for $def/$ref.