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.

[KKonstantinov]

Hi, this PR seems like a good addition

Took the liberty to try & push this along..

There were a few stuff:
-> Reserved metadata validation was missing
-> Prefix validation was missing (regex)
-> Name validation was missing (regex)
-> Not sure if relevant, but filtering out reserved metadata entries if coming (somehow) from storage

Doing this on a late night, lmk if anything missed out / needs reworked so to try & finalize this.

[ln-12]

Sorry, I was blocked by other topics lately. Will try to look at it this week. Thanks for the support!

[ln-12]

Merged master to fix the failed builds, tested the changes locally and so far it looked good. @cliffhall could you please check again?

[cliffhall]

@KKonstantinov @ln-12 I'm seeing some validation errors that don't make sense. The error says hyphen, underscore, and dot are allowed, but those characters trigger the validation error:

[cliffhall]

@KKonstantinov @ln-12
Also, I see unit tests that check if the prefix of a meta key is modelcontextprotocol.io, but I do not see any lines where that is specifically being looked for in the key.

I see that modelcontextprotocol is included in RESERVED_NAMESPACE_LABELS

However, entering it in the textbox does not trigger a validation error

[cliffhall]

Validation still has some kinks in it. See above comments.

[KKonstantinov]

Hi @cliffhall , thanks for reviewing.

Please check the docs, the validations are aiming to follow exactly as the docs state (not claiming there are no issues, but addressing the ones below)

https://modelcontextprotocol.io/specification/2025-06-18/basic/index#meta

Prefixes
The reserved keywords apply for prefixes only.

Any prefix beginning with zero or more valid labels, followed by modelcontextprotocol or mcp, followed by any valid label, is reserved for MCP use.

What is a prefix?

If specified, MUST be a series of labels separated by dots (.), followed by a slash (/).
Labels MUST start with a letter and end with a letter or digit; interior characters can be letters, digits, or hyphens (-).

Names
If modelcontextprotocol is used just as a name, like on the screenshot you provided, there's no wording that should be forbidden. We could decide to not allow it - which is what I did here, but it wouldn't be per spec (or the spec needs updating).

To clarify a bit, the spec says that no prefix can contain "modelcontextprotocol" or "mcp" , and modelcontextprotocol.io and mcp.dev are just given as examples.

Any prefix beginning with zero or more valid labels, followed by modelcontextprotocol or mcp, followed by any valid label, is reserved for MCP use.

The above includes any subdomain and any extension, including made up ones (e.g. "whatever.modelcontextprotocol.tld" should still error out.

Why did it error out when you tried . - etc. Because in your examples, you're finishing the name with these symbols, and that's not allowed.

Unless empty, MUST begin and end with an alphanumeric character ([a-z0-9A-Z]).

If you add something after it, e.g. abc.xyz or abc-xyz will work. But abc., abc- won't.

[cliffhall]

Hi @cliffhall , thanks for reviewing.

Please check the docs, the validations are aiming to follow exactly as the docs state (not claiming there are no issues, but addressing the ones below)

Yep, you're right. A lot of words were devoted to reserving <subdomain>.[mcp|modelcontextprotocol].<tld>; it seems an oversight that modelcontextprotocol/label or mcp/label should be allowed. But that's how it reads.

[cliffhall]

Tested locally. LGTM! 👍