Enables tools to include arbitrary metadata that gets returned in tools/list responses. Includes comprehensive tests and maintains backward compatibility.

Motivation and Context

The MCP specification already defines support for the _meta field in tool definitions, but the TypeScript SDK wasn't implementing it. This change was needed to:

• Allow tool authors to include metadata
• Enable clients to access tool metadata
• Provide a standardized way to attach arbitrary metadata to tools following the MCP specification for _meta usage

Without this feature, tool authors had no way to provide additional context about their tools beyond the basic name, description, and schema.

How Has This Been Tested?

• Unit tests: Added comprehensive tests covering both tools with and without _meta fields
• Integration tests: Full end-to-end testing with client/server communication via tools/list requests
• Backward compatibility: Verified existing tools without _meta continue to work and return undefined
• Build verification: All TypeScript compilation passes for both ESM and CommonJS targets
• Test suite: All 727 existing tests continue to pass, plus 2 new tests specifically for _meta functionality

The implementation has been tested with various metadata scenarios including nested objects, arrays, and different data types.

Breaking Changes

None. This is a fully backward-compatible addition:

• Existing tools without _meta continue to work unchanged
• The _meta field is optional in all interfaces
• No changes to existing method signatures or behavior

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Implementation Details:

• Added _meta?: Record<string, unknown> to RegisteredTool type
• Updated registerTool config interface to accept _meta parameter
• Enhanced _createRegisteredTool method to handle _meta storage and updates
• Modified ListToolsRequestSchema handler to include _meta in responses

Design Decisions:

• Used Record<string, unknown> type to allow maximum flexibility while maintaining type safety
• Ensured _meta is completely separate from the request-level _meta (used for progress tokens)
• Made the field optional everywhere to maintain backward compatibility
• Following the existing pattern used by other optional fields like annotations
• Adheres to the MCP specification's _meta field guidelines

Security Considerations:

• No security concerns identified - only exposes developer-provided metadata
• No mixing between request-level _meta and tool definition _meta
• Follows the same security model as other tool metadata fields