Pass request _meta to request handlers extra param

[iamarcel]

Motivation and Context

The MCP client sends a progress token when calling tools, but there's currently no way for the server (in this SDK) to retrieve this progress token. While the client will receive the progress notifications, it won't associate them with the tool calls and thus it can't properly report on progress.

How Has This Been Tested?

In the inspector, of course, and my chat MCP client (SSE server).

Here's the setup, roughly:

// Server
server.tool(
  "hello",
  { city: z.string() },
  async ({ city }, { sendNotification, _meta }) => {
    if (_meta?.progressToken) {
      await sendNotification({
        method: "notifications/progress",
        params: { progress: 1, progressToken: _meta.progressToken }
      })
    }

    return {
      content: [{ type: "text", text: `Hello, ${city}!` }]
    };
  }
);

// Client
await client.callTool(
  { name: "hello", arguments: { "city": "Ghent" } },
  undefined,
  {
    onprogress: progress => console.log("Hello progress", progress)
  }
);

Breaking Changes

None.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

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

This is the smallest possible way to implement the functionality in the SDK, but I'm not convinced on the ergonomics as a user.

I'm open to hear your ideas:

• Should we add a sendProgress(progress: number, total?:number) in the extra params instead? The Python SDK has a report_progress that it passes to the request context.
• Does the progressToken make sense, actually? There's already a relatedRequestId passed through by sendNotification—maybe that should be used instead of a separate progress token?

[pulkitsharma07]

This is helpful, can this be merged @cliffhall ?

[flippinjoe]

+1 for this. Looks like there's a conflict that needs to fixed

[cliffhall]

If the ProgressToken gets its own schema, why not the request metadata? Certainly helps with handling that request meta object on its own, since it gets its own inferred type. LGTM! 👍

@jspahrsummers

[ihrpr]

Does the progressToken make sense, actually? There's already a relatedRequestId passed through by sendNotification—maybe that should be used instead of a separate progress token?

relatedRequestId is not part the spec, it's an implementation choice, where progressToken in _meta field is part of the spec

[ihrpr]

Looks good, thank you

[ihrpr]

@iamarcel please can you fix the build and then we can merge?

[iamarcel]

@iamarcel please can you fix the build and then we can merge?

Yes! Rebased it on the latest version—the merge before messed up.