SDK v1.9.0: Incompatibility between Tool Registration Limitations and Client Parameter Passing

[eladmint]

Describe the bug

With @modelcontextprotocol/sdk v1.9.0, it's not possible to register tools requiring structured input parameters in a way that allows MCP clients (like Cursor) to successfully pass those parameters. Attempts to register with an explicit inputSchema fail at build time, and the necessary workaround (using an adapter pattern) results in the client not sending parameters correctly (they arrive as undefined on the server). This prevents tools needing input from functioning.

To Reproduce
Steps to reproduce the behavior:

1. Initialize an MCP server using @modelcontextprotocol/sdk v1.9.0 and SseServerTransport.
2. Define a tool handler function (myHandler) that expects a structured input object, validated by a Zod schema (MyInputSchema).
3. Attempt 1 (Direct Schema Registration - Fails):
   Try registering the tool using server.tool('my_tool', { description: '...', inputSchema: MyInputSchema, handler: myHandler }).
   Observe TypeScript build errors (TS2345 or similar), indicating this registration signature is invalid.
4. Attempt 2 (Adapter Pattern Workaround - Necessary but Problematic):

• Define an adapter handler:
  const adapterHandler = async (extra: MinimalRequestHandlerExtra) => {
  try {
  // Expect parameters in extra.input
  const parsedInput = MyInputSchema.parse(extra.input); // <- Fails here at runtime
  // ... call original myHandler with parsedInput ...
  } catch (error) {
  // ... handle error ...
  }
  };
• Register the tool using the supported signature: server.tool('my_tool', adapterHandler as any);

5. Client Invocation:

• Connect an MCP client (e.g., Cursor) to the server.
• Invoke 'my_tool' from the client, attempting to pass parameters according to MyInputSchema.

6. Observe Server:
   Log the extra object received by adapterHandler. Note that it lacks the input field (e.g., only contains {"signal":{},"sessionId":"..."}).
   Observe the ZodError thrown when MyInputSchema.parse(extra.input) is executed because extra.input is undefined.

Expected behavior
Ideally, tool registration with an explicit inputSchema should be supported (Attempt 1). If not, when using the adapter pattern workaround (Attempt 2), the MCP client should successfully send the parameters such that they are accessible within the extra object on the server (specifically, extra.input should contain the structured parameters), allowing the adapter to parse them and call the underlying tool logic.

Logs

• Build Time (Attempt 1): TypeScript error TS2345: Argument of type '{ description: string; inputSchema: ZodSchema<...>; handler: ...; }' is not assignable to parameter of type '(extra: RequestHandlerExtra) => ...' (or similar object property error).
• Runtime (Attempt 2 - Server Log):
  // Log entry showing the 'extra' object received by the adapter handler
  DEBUG [SDKServer-Minimal] [adapterHandler] Received extra object: {"signal":{},"sessionId":"..."}
  // Log entry showing the Zod parsing error
  ERROR Input validation failed for my_tool: [ { "code": "invalid_type", "expected": "object", "received": "undefined", "path": [], "message": "Required" } ]

Additional context
SDK Version: @modelcontextprotocol/sdk@1.9.0 (latest)
Transport: SseServerTransport
Server Environment: Node.js v18+, TypeScript
Client Tested: Cursor
Impact: This currently blocks functional testing and usage of any tool requiring structured input parameters. The adapter pattern seems necessary due to SDK limitations but breaks parameter passing from the client.

[felixweinberger]

Potentially related to #622