feat: Enable tool handlers to use "_meta" from req

[jpmcb]

This patch enables a tool handler to accept an optional _meta argument: this is in support of the OpenAI apps sdk which recommends passing UI widget state along in the tool call/resp _meta field. This ensures that clients don't have to pass along all the content or structuredContent to the LLM.

Notice in the examples/servers/apps-sdk, this now uses _meta for the todo list's full state and the structuredContent now carries only the current todos.

[Copilot]

Pull request overview

This PR enables tool handlers to accept an optional _meta parameter from tool call requests, supporting the OpenAI Apps SDK pattern where UI widget state is passed via _meta rather than in the content shown to the LLM.

Key Changes:

• Updated handler signatures in ToolConfig and RegisteredTool to accept optional _meta parameter
• Modified handleToolCallRequest to pass toolCallReq.params._meta to tool handlers
• Updated the apps-sdk example to demonstrate returning full state in _meta while keeping structuredContent minimal (non-completed todos only)

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/tools/types.ts	Added optional _meta parameter to handler signature in ToolConfig
src/server/types.ts	Added optional _meta parameter to handler signature in RegisteredTool
src/server/index.ts	Modified handleToolCallRequest to pass _meta from request to handler
examples/servers/apps-sdk/src/index.ts	Updated todo app example to return full state in _meta and filtered todos in structuredContent

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[Copilot]

The _meta parameter type in the handler signature is object | undefined, but according to the schema definition in src/jsonrpc2/schemas/request.ts, toolCallReq.params._meta is typed as RequestMeta | undefined (which has a progressToken?: string | number field and allows additional properties via .loose()). This type mismatch could lead to type safety issues.

Consider updating the handler signature to use a more specific type that matches the schema, or explicitly document why the generic object type is used here.

[jpmcb]

We're not really supporting progressToken in any meaningful way: this simply passes along the object to the called handler and it can do something with it / infer the progressToken itself

[franz-zuplo]

LGTM!