MCP: Support Sampling

[digitarald]

Enable secure LLM delegation through MCP’s sampling protocol, allowing servers to request AI completions while preserving client control over model selection and data privacy.

• User approval flow for all sampling requests
• Visible context sources in generated responses
• Model hint mapping to available providers
• Safety limits on temperature/max_tokens
• Media type validation/caching

[beingminimal]

@digitarald

To support all these Concepts of MCP this issue should be in next month's milestone, Please consider it.
Sampling

[connor4312]

PR's welcome ;)

[kentcdodds]

I tried out the sampling support available in insiders and I have a few items of feedback:

1. It's great! So nice to be able to use this feature now!
2. I would like to be able to see the system prompt, messages, and other config for each sampling request before I approve it. This would help increase trust in the server (that it's not going to just abuse my LLM tokens)
3. In my testing, the configured system prompt doesn't seem to work or count for much somehow. I had to move the system prompt to a user message instead to get the output to be formatted properly. (On that note, https://github.com/orgs/modelcontextprotocol/discussions/385 would probably help improve the reliability of this.)

Here's a snippet of what I've got currently:

	const result = await agent.server.server.createMessage({
		systemPrompt: `
You are a helpful assistant that suggests relevant tags for journal entries to make them easier to categorize and find later.
You will be provided with a journal entry, it's current tags, and all existing tags.
Only suggest tags that are not already applied to this entry.
Journal entries should not have more than 4-5 tags and it's perfectly fine to not have any tags at all.
Feel free to suggest new tags that are not currently in the database and they will be created.

You will respond with JSON only.
Example responses:
If you have no suggestions, respond with an empty array:
[]

If you have some suggestions, respond with an array of tag objects. Existing tags have an "id" property, new tags have a "name" and "description" property:
[{"id": 1}, {"name": "New Tag", "description": "The description of the new tag"}, {"id": 24}]
			`.trim(),
		messages: [
			{
				role: 'user',
				content: {
					type: 'text',
					mimeType: 'application/json',
					text: JSON.stringify({ entry, currentTags, existingTags }),
				},
			},
		],
		maxTokens: 100,
	})

I would love to know whether I'm doing something wrong here! Thanks!

[digitarald]

Yes, the spec for systemPrompt is optional The client MAY modify or omit this prompt.. We omit it as we avoid user-generated content in system prompts. I suggest depending on the user prompt which will yield similar results. This would be worth bringing back to the spec as hard to progressively support.

[kentcdodds]

I missed that part of the spec. Thanks a lot!

[connor4312]

I would like to be able to see the system prompt, messages, and other config for each sampling request before I approve it. This would help increase trust in the server (that it's not going to just abuse my LLM tokens)

Definitely, we're thinking about "async UI" for chat and I expect we will reuse some of that for improved sampling views.

In my testing, the configured system prompt doesn't seem to work or count for much somehow.

We do ignore this... but I think we should include it somehow when present, even if just rewritten as a user message. I will fix this.

[kentcdodds]

The client MAY modify or omit this prompt

I'm trying to find this in the spec but cannot.

[connor4312]

I think supporting the system message is fine, we give extensions the ability to use that through the vscode.lm APIs, so no reason an MCP server couldn't. Added in the linked PR.

Going to close this since we delivered the feature this past iteration. Future improvements should be tracked in their own issues.