feat(server): add onInputValidationError callback

[travisbreaks]

Summary

Adds an optional onInputValidationError callback to McpServerOptions that fires before the validation error is returned to the client when a tool call fails input schema validation.

This enables servers to add logging, metrics, or other observability for invalid tool calls without having to intercept responses downstream or skip inputSchema entirely.

Closes #1160

Changes

• Added McpServerOptions type extending ServerOptions with an optional onInputValidationError callback
• Added InputValidationErrorCallback type (exported for consumer use)
• Updated McpServer constructor to accept McpServerOptions and store the callback
• Updated validateToolInput to invoke the callback (if set) before throwing the validation error
• The callback receives { toolName, arguments, issues } for full observability

Usage

const server = new McpServer(
  { name: 'my-server', version: '1.0.0' },
  {
    onInputValidationError: ({ toolName, arguments: args, issues }) => {
      console.warn(`Invalid args for ${toolName}:`, issues);
      metrics.increment('tool.input_validation_error', { tool: toolName });
    }
  }
);

Test plan

• Callback is invoked with correct tool name, arguments, and issues on validation failure
• Callback is not invoked when validation succeeds
• Async callbacks are properly awaited before the error is returned
• All existing tests pass (389/389)
• Lint passes

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

[changeset-bot]

🦋 Changeset detected

Latest commit: a6dd2a9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@modelcontextprotocol/server	Minor
@modelcontextprotocol/express	Major
@modelcontextprotocol/hono	Major
@modelcontextprotocol/node	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1713

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1713

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1713

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1713

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1713

commit: a6dd2a9

[felixweinberger]

Thanks for this. Before adding a dedicated callback: have you tried logging validation failures at the HTTP/transport layer? The validation error is returned as a JSON-RPC InvalidParams (-32602) response, which your framework middleware (Express/Hono/Fastify) can observe and log. That avoids adding per-event hooks to the SDK, which tend to proliferate (onOutputValidationError, onToolNotFound, etc. would be next). If transport-level logging doesn't cover your use case, happy to discuss further.