Force returning tool result/ressource as artifact without regeneration

[maxschulz-COL]

Is your feature request related to a problem? Please describe.
The problem I am facing is that I am currently creating an MCP server that through tools creates artifacts (python code, html code)

There is no problem in the model receiving the outcome, but when it presents it in the chat, it essentially regenerates it which causes the following problems:

• slight alterations
• token usage
• speed

Describe the solution you'd like
I would like to be able to enforce the direct return of the tool/ressource.

If using Claude desktop, I would like to even return the output as an artifact, but that is of course specific to anthropic/Claude

Examples:

• Tool creates a custom URL, Ideally this becomes visible in chat as is, quickly and without alteration
• Tool creates Python code, ideally this is just visible as is in the chat OR even claude artifacts

Describe alternatives you've considered
I have tried to prompt/describe my tools to enforce this, but this did not work

Additional context
I am not sure if this is the correct place to ask, but would be very keen to discuss this as I can imagine it is a common problem?

I can also help refine the problem statement a bit more if that's of interest

[dulnoan]

I'm tackling the same problem. Looks like this is similar to: https://python.langchain.com/docs/how_to/tool_artifacts/#creating-from-basetool-class

But what we want ideally is to send the artifact (complete dataset i.e a CSV or JSON) back to the end user. For example, the AI gives a response listing the top 10 items out of 100 from the dataset, and the full 100 dataset is an artifact in the API response which can be extracted should the user need the full dataset.

Any help would be greatly appreciated!

[linkous8]

Over on the Java side of the fence, they're using a returnDirect flag in the ToolAnnotations to support indicating when a tool call should not be sent as a response to the model

modelcontextprotocol/java-sdk#313

Would it be a good idea for the python SDK to follow this approach?

The spec is left intentionally open ended (per modelcontextprotocol/modelcontextprotocol#185 (comment)) but if python and Java SDKs both implement a returnDirect annotation then that may provide sufficient impetus to have it added to the specification.

[linkous8]

After a bit more digging, it seems like the _meta fields are pretty well suited to this purpose

python-sdk/src/mcp/types.py

Lines 857 to 861 in 6a84a2f

	meta: dict[str, Any] | None = Field(alias="_meta", default=None)
	"""
	See [MCP specification](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/47339c03c143bb4ec01a26e721a1b8fe66634ebe/docs/specification/draft/basic/index.mdx#general-fields)
	for notes on _meta usage.
	"""

Direct display doesn't really impact the protocol itself, its more of an implementation concern in terms of server advertised capabilities and client handling thereof.

That said, the maintainers on both client and server side would have to agree on the keys and format of the meta object for communicating this. This works fine for my use case since I maintain both ends but may pose a challenge when it comes to Claude Desktop and Langchain supporting the functionality.

@maxschulz-COL short term, you could try approaching Claude Desktop support to see if they can provide some sort of interim implementation on the client side that your server could then adhere to. Long term, this seems like something worth standardizing in the MCP specification via the working group https://modelcontextprotocol-community.github.io/working-groups/index.html

[kasuteru]

What is the status of this? We are facing the same issue - we want our MCP server to generate a data artifact that the client should store / visualize but not put into the context window, for the aforementioned reasons (context window bloat, danger of switching a number, cost...)

[waddah12alhajar]

any updates on this issue?

[shishir-github]

We also have a similar requirement. It will be really helpful to have "returnDirect" option added to python SDK