Added UI to provide additional _meta values

[ln-12]

This PR adds a UI section inside the tools tab which enabled the user to provide extra key-value pairs for the _meta object. Fixes #559.

UI:

Request:

Motivation and Context

Currently there is no way to provide additional _meta values in the UI.

How Has This Been Tested?

I provided values in the UI and checked that they are sent in the request. Also, I added a test.

Breaking Changes

No

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

[ln-12]

I also added another section to the main UI so that it is possible to add meta data for all calls (like initialize, tools/list, ...):

[cliffhall]

I like this!

Tested locally with prompts/list resources/list, resources/subscribe, resources/unsubscribe, resources/templates/list, completion/complete, resources/read, tools/call, and tools/list.

However,

Can we just make this "Metadata"? I understand it's "data for the _meta param" but Metadata is a word. Meta Data is weird.

And make MetaDataTab be MetadataTab.

[ln-12]

I tried to satisfy all you suggestions. For the cli test, we would need to update the everything server first to somehow react to metadata and/or return the submitted values in the echo tool to make sure the values are passed along. The added test for now only check if passing values is successful.

[cliffhall]

Left some inline notes, but also, can you remove the metadata-test-output folder and files and add the folder to .gitignore?

[cliffhall]

Hey @ln-12!

Thanks for clearing up the test logging.

In testing this locally though, it seems like there's been a slight regression since the first time I tested this.

If I remember correctly,

• When I set a metadata pair on the Metadata tab, it should go out on all calls, including tool calls.
• If I set tool-specific metadata, it should go out on that tool call, and if it is the same key as a key set on the Metadata tab, it overrides that.

What I'm now seeing is that I set a pair on the Metadata tab, and then I do tools/list and I see the pair (this/that):

However when I make a tool call, the pair is not there:

But if I add tool-specific metadata, it will be added to the tool call

[cliffhall]

Test logging issue and naming issue straightened out, but now there's a regression in sending general metadata to tool calls.

[ln-12]

Good catch, I accidentally shadowed the metadata state field when renaming the function parameter. I checked it again locally and all combinations of general and tool metadata work as expected for me now.

[cliffhall]

Looking good so far, tool-specific metadata is being sent in addition to general metadata.

However, it allows me to send reserved keys, and that should be prohibited. Please review the spec on the matter of reserved keys and make sure they're all disallowed.

In this case I'm sending a key of modelcontextprotocol.io/flip and it is allowed.