Is your feature request related to a problem? Please describe.
Currently, I am developing an MCP server that manages prompt templates for parameterized invocation by clients. The current implementation follows a pattern like promptsHolder.getPrompt({name: "myPrompt", arguments: {...}}), which returns an array of messages to send to the LLM agent.
Some of my prompts require a specific output format from the LLM. At present, I rely on few-shot prompting techniques to enforse desired structured output. However, this approach sometimes leads to inconsistent results, such as not expected enums values, or markdown-style quotation.
Describe the solution you'd like
I propose that the MCP server should be able to specify a JSON schema for the expected response. The schema definition would take place on the server side, while the client would handle the final adaptation for specific host models. A common option to consider could be response_format.
A potential implementation might look like this:
/server/api/getPrompt/myPrompt
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"description": "Code review prompt",
"options": {
"response_format": {"type": "json_object", "schema": __jsonSchema__},
}
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": "Please review this Python code:\ndef hello():\n print('world')"
}
}
]
}
}
Describe alternatives you've considered
- few shots prompting, that works in most cases, but misfires time to time
- tool calling, when the tool with structured params definition is provided to the model — this is common workaround, and even anthropic recommended to use it as claude does not accept a schema parameter, but it still a workaround which add unnecessary complexity
Additional context
There is related discussion #97 and even same question is raised, but that topic is generally consider another feature.
I understand that such feature significantly increases API-surface. And at least raise some questions.
Server can't be sure for 100% that client or host implement that feature. So it need to proceed validation on own side and even raise errors. Should it be reflected in protocol somehow? Like a requirement from the client to inform the server about the available options.
Would appreciate your thoughts about this feature. Would it be on roadmap or better to consider alternative options?
Is your feature request related to a problem? Please describe.
Currently, I am developing an MCP server that manages prompt templates for parameterized invocation by clients. The current implementation follows a pattern like
promptsHolder.getPrompt({name: "myPrompt", arguments: {...}}), which returns an array of messages to send to the LLM agent.Some of my prompts require a specific output format from the LLM. At present, I rely on few-shot prompting techniques to enforse desired structured output. However, this approach sometimes leads to inconsistent results, such as not expected enums values, or markdown-style quotation.
Describe the solution you'd like
I propose that the MCP server should be able to specify a JSON schema for the expected response. The schema definition would take place on the server side, while the client would handle the final adaptation for specific host models. A common option to consider could be response_format.
A potential implementation might look like this:
Describe alternatives you've considered
Additional context
There is related discussion #97 and even same question is raised, but that topic is generally consider another feature.
I understand that such feature significantly increases API-surface. And at least raise some questions.
Server can't be sure for 100% that client or host implement that feature. So it need to proceed validation on own side and even raise errors. Should it be reflected in protocol somehow? Like a requirement from the client to inform the server about the available options.
Would appreciate your thoughts about this feature. Would it be on roadmap or better to consider alternative options?