Skip to content

Conversation

@yanOO1497
Copy link
Contributor

@yanOO1497 yanOO1497 commented Oct 25, 2025

Motivation and Context

Previously, when a tool's input schema contained $ref references (e.g.,
"$ref": "#/properties/source"), the ToolsTab component would incorrectly
render the referenced property as an object type instead of resolving
the reference to the actual schema definition.

This caused issues where properties that should inherit from other
properties (like string types with validation rules) were rendered as
complex object forms instead of simple input fields.
before:
image

after:
image

image

How Has This Been Tested?

Tested with MCP tools that use $ref references in their input schemas.
For example, a schema with:

{
  "properties": {
    "source": {
      "type": "string",
      "minLength": 1,
      "description": "test"
    },
    "target": {
      "$ref": "#/properties/source"
    }
  }
}

Now correctly renders both source and target as string input fields
with the same validation rules, instead of rendering target as an
object form.

Breaking Changes

No breaking changes.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally

@cliffhall cliffhall added the bug Something isn't working label Oct 29, 2025
@Edison-A-N
Copy link

Thanks for working on this! 🎉

I was also tackling Issue #897 and noticed a couple of additional scenarios that might need attention:

  1. $defs support: Your current implementation handles #/properties/name but not #/$defs/UserRole format
  2. anyOf=[$ref, null] enum handling: When schema has anyOf: [{$ref: "#/$defs/UserRole"}, {type: "null"}], the enum values might still be lost
  3. Optional enum clearing: Users can't clear optional enum fields back to undefined

I've been working on these cases in my branch fix/enum-ref-resolution-and-clear-option - would love to get your thoughts on the approach and see if we can collaborate on a complete solution!

Copy link
Member

@cliffhall cliffhall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing, but this looks good so far.

cliffhall added a commit to cliffhall/mcp-maintainer-toolkit that referenced this pull request Oct 30, 2025
See modelcontextprotocol/inspector#889

* In tools.ts
  - modified AddSchema
    - tests simple primitive refs
    - extracted z.number() to a variable that is referenced for a and b properties
  - modified ComplexOrderSchema
    - tested object refs
    - extracted shipping address properties to address variable
    - referenced address from shippingAddress property
    - added billing address property that references address
@cliffhall
Copy link
Member

Thanks for working on this! 🎉

I was also tackling Issue #897 and noticed a couple of additional scenarios that might need attention:

  1. $defs support: Your current implementation handles #/properties/name but not #/$defs/UserRole format
  2. anyOf=[$ref, null] enum handling: When schema has anyOf: [{$ref: "#/$defs/UserRole"}, {type: "null"}], the enum values might still be lost
  3. Optional enum clearing: Users can't clear optional enum fields back to undefined

I've been working on these cases in my branch fix/enum-ref-resolution-and-clear-option - would love to get your thoughts on the approach and see if we can collaborate on a complete solution!

Hi @Edison-A-N!

I've just tested this one and it looks pretty good. I am going to go ahead and merge it since it seems rather simple. But the cases that you are working on need to be fixed as well, particularly $def. That change should fix #755. Please tag me when you have a PR ready.

Copy link
Member

@cliffhall cliffhall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested with simple primitive refs as well as object refs that live in properties with this PR for the mcp-maintainer-toolkit. Tests run, linter is happy. LGTM! 👍

Image Image Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants