Issue
In the Typescript SDK ToolSchema (Tool in Python SDK) has a different inputSchema shape (https://github.com/modelcontextprotocol/typescript-sdk/blob/main/src/types.ts#L764-L768) than Tool in Python SDK (https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/types.py#L715). It looks like Tool is underspecified in Python SDK as it is defining inputSchema as an arbitrary dict[str, Any]. By contrast in Typescript SDK inputSchema always has type and properties fields. All the examples here: https://modelcontextprotocol.io/docs/concepts/tools also have type and properties fields.
Proposal
Ideally we would update Python SDK to conform to the inputSchema contract if it is intended to be as strict as that of Typescript. Since this is a backwards incompatible change we should consider how we want to roll this out. More generally with a fast-growing protocol like this we should think through the right way to make these kinds of changing (major versions maybe the best approach).
Issue
In the Typescript SDK ToolSchema (Tool in Python SDK) has a different inputSchema shape (https://github.com/modelcontextprotocol/typescript-sdk/blob/main/src/types.ts#L764-L768) than Tool in Python SDK (https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/types.py#L715). It looks like Tool is underspecified in Python SDK as it is defining
inputSchemaas an arbitrarydict[str, Any]. By contrast in Typescript SDKinputSchemaalways has type and properties fields. All the examples here: https://modelcontextprotocol.io/docs/concepts/tools also have type and properties fields.Proposal
Ideally we would update Python SDK to conform to the inputSchema contract if it is intended to be as strict as that of Typescript. Since this is a backwards incompatible change we should consider how we want to roll this out. More generally with a fast-growing protocol like this we should think through the right way to make these kinds of changing (major versions maybe the best approach).