modelcontextprotocol
Force returning tool result/ressource as artifact without regeneration
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
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!
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
https://github.com/modelcontextprotocol/java-sdk/pull/313
Would it be a good idea for the python SDK to follow this approach?
The spec is left intentionally open ended (per https://github.com/modelcontextprotocol/modelcontextprotocol/pull/185#discussion_r2010038690) but if python and Java SDKs both implement a returnDirect annotation then that may provide sufficient impetus to have it added to the specification.
After a bit more digging, it seems like the _meta fields are pretty well suited to this purpose https://github.com/modelcontextprotocol/python-sdk/blob/6a84a2f79f4feaca59461f3c879d7482c6d85dec/src/mcp/types.py#L857-L861
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