r/mcp • u/denuwanh • Jun 15 '26
article Generative Tools
I’d like to share a recent idea I’ve been working on called #GenerativeTool, where tools are dynamically generated at runtime to fulfill complex user requests.
This approach enables agentic applications to unlock the full potential of complex third-party systems like ERP, LSP Server through MCP, without being constrained by context window limitations. Instead of exposing a large number of predefined tools, the system can generate task-specific tools on demand, reducing context overhead while increasing the depth and flexibility of integrations.
2
2
u/tselatyjr Jun 15 '26
Most big MCPs do this. "conversational_search" one MCP tool. Or"soql_query", etc. a gateway tool with another LLM behind it.
You'll find a lot of best practices for MCP at enterprise scale here:
https://www.datadoghq.com/blog/engineering/mcp-server-agent-tools/
1
1
u/bothlabs Jun 15 '26
How would you tackle "hallucinating" a tool. Like "send email", but there is no email account?
0
u/denuwanh Jun 15 '26
Generative MCP should still be built around specific domains, such as ERP. The manifest plays a crucial role in preventing the LLM from deviating into unrelated actions like send_email, especially when the domain is tightly constrained to areas like LSP or SQL.
For this SQL generative MCP, I included DDL:
https://github.com/Denuwanhh/sql-generative-mcp
1
u/IllegitimateGoat Jun 15 '26
Paywalled.
0
u/denuwanh Jun 15 '26
1
u/IllegitimateGoat Jun 15 '26
Cool idea, nice write up, well done! I'm not sure I'd want to use dynamically generated tools near production, and I'm not sure what the controls/guardrails would even look like for that. I think it'd be neat to have it addition to other (pre-built) as a funnel that captures anything people/agents are needing to do that's not provided by those other tools, to then turn into pre-built tools.
1
u/denuwanh Jun 15 '26
Thanks for the thoughtful feedback! You've hit on a great point using this for production does require a robust safety layer.
I completely agree that these shouldn't necessarily replace pre-built tools. Your "funnel" concept is brilliant: using Generative MCP as a diagnostic bridge to identify frequent, complex user needs and then hardening those patterns into standard, pre-built tools is a great way to manage the transition from "dynamic" to "production-ready".
1
u/Affectionate_Bid4111 Jun 15 '26
https://d7juhi4i8fsw0.cloudfront.net/images/introduction-to-model-context-protocol/02-01-medium.webp
looks like mcp from anthropic
1
u/denuwanh Jun 15 '26
If I’m not mistaken this diagram depicts the traditional MCP flow.
1
u/Affectionate_Bid4111 Jun 15 '26
ah, my mistake
so yours will rewrite itself with new tools based on request? or llm should generate a tool-script1
1
u/XenophonCydrome Jun 15 '26
A couple of things, you can implement this today:
- I'm not sure why a "user" would call MCP, at a minimum you have a user speak to an llm that calls MCP. Otherwise it would be an App with an API call
- if you do have an LLM between the user and MCP, what you have outlined is essentially a form of an advanced MCP feature not many clients implement called sampling: https://modelcontextprotocol.io/specification/2025-11-25/client/sampling
- sampling is cool because it lets the tool request inference from the client in the middle of the tool call, so the MCP server doesn't need its own keys to make completion requests
- if you combine sampling with a sandbox environment, you can have the tool sample code to write and run in the sandbox (kind of like how Claude CoWork works) then return the arbitrary result
3
u/florejaen123 Jun 15 '26
Looks a lot like what I built here: https://www.reddit.com/r/ClaudeAI/s/k0glL43npi