Repository navigation
Enhancement: Ability to ask user before making Tool Call #5580
Description
Activity
I like the current implementation that when you configure an agent that is just uses that tool. So I would vote for a configurable option per tool when to get a user in the loop.
Reacted by Jason Melis, Philipp Wirtenberger, Tobias Jonas, Ian D'Ambrosio, Adam Weber, David Markey, Thomas Cerbelaud, lucasBertolaAgicap, Matthis, heptapod and 7 moreReacted by amengus87 and Benjamin Bachmayr- marked [Enhancement]: Support for MCP tool call approval #7564 as a duplicate of this issue
on May 26, 2025 I am considering contributing towards this issue but a bit lost about how best to continue. I feel like there are many possible ways and opinions about how to implement such a feature and I am unsure how consent about something like this is usually reached in this project.
Personally, I feel it's very important for "read write" kind of tools to be guarded by user confirmation. Imagine an ai agent with tools for working with a ticket system - you wouldn't want it to have the ability to close or forward tickets without your explicit control. Especially in a company setting, where employees might try to deflect responsibility towards an AI when shit hits the fan ;)
I also agree not every tool needs user verification, so it should be selective somehow. I believe it's challenging to design the verification in a way that's easy to understand for the user and not too annoying. E.g. showing the tool verification as (distinguishable) part of the chat messages, and instead of denying explicitly you just type your next message and tool use will be denied automatically. That way the AI model would get context about why the tool use was denied and what should be done instead.
I am not sure if every model provider would play well with receiving a human message after a tool call or tool call response though.
What are your thoughts here?
Reacted by Walber Cardoso, Nicolas De Boose and Benjamin BachmayrYep, that's essential for tools that change data. The way Zed implemented it is cool:
@danny-avila is this reasonable with the current architecture? What would be the next steps for contributing to this?
Reacted by Jin Yao and Red5d- marked [Enhancement]: Request Tool use confirmation #8023 as a duplicate of this issue
on Jun 23, 2025 @owengo is it really elicitation? This is to confirm before calling tool, elicitation to the extent I understood is server initiated request hence part of tool's execution flow (i.e. tool has already been called its asking for confirmation only if code is written like that).
Yes, the "elicitation" message is sent by the MCP during tool execution ( typically before doing the actual action ). The server waits for the client's response ( the client in LC in our case ) before going on.
The mechanism was added to the MCP spec in june and is aimed to make some sttandardization of the human-in-the-loop mechanics.https://modelcontextprotocol.io/specification/2025-06-18/client/elicitation
It's not quite the same thing, but for servers that support it, it allows more elegant human-in-the-loop capabilities for critical tool calls.
I think that letting the tool, instead of the client, decide wether confirmation is needed or not is a good approach, even if we've been used to the other way because of how chatgpt handles tool usage.
Also the spec handles more than just confirmation, it allows to require supplementary data that will not pass thru the llm. For example your email / post address won't be copy-pasted by the llm but directly passed from the client to the mcp server in the elicitation response.Obviously the issue right now is that very few MCP servers support the new spec, but hopefully it will change quickly thanks to spec adoption / adherence. If claude code supports it, the main vscode forks & extension will follow and it will be the new norm.
If the client supports the protocol and the server does not, it's always possible for the client to generate an elicitation itself /before/ the tool call and benefit from the existing, unified client-side implementation. It would probably fit your use-case @fstadt .
Note that client side there are still many things to handle:
- the elicitation rendering
- maybe allowing an answer memorization ( always accept this tool, always put my email in the email form from this elicitation etc .. )
- timeout management
This is still a security issue. What if tool does not implement safety checks and LLM hallucinate and run the tool with some irrecoverable arguments?
I'm looking for a way to ask for confirmation before running the tool and it seems like even after proper prompt to ask for confirmation, the llm still calls the tool anyway.
I think that letting the tool, instead of the client, decide wether confirmation is needed or not is a good approach, even if we've been used to the other way because of how chatgpt handles tool usage.
Just to add my perspective, confirmation would be useful even for tools that don’t mutate data. If you use LibreChat to handle sensitive information you risk accidental disclosures if you have any tools enabled. Exposing the exact payload before calling a tool lets you catch any unintended disclosures .
Even if all MCPs bake in elicitation logic for approvals, I don't think it achieves quite the same thing this kind of configurable feature would. People are going to disagree which tool calls need user confirmation since it often depends on context.
Reacted by Animesh SahuHello, I also think it's a security issue, especially when MCP actions are triggered via the
submitparameter in the URL of the Automatic Prompt Submission.Reacted by Daniel Höxtermann and Animesh SahuAgreed, this really ends up being pretty important for any non-trivial use cases. The Always Allow / Allow / Deny flow someone mentioned above kinda feels like a sweet spot for now getting in the users way if they really don't want it to, but providing some level of accountability and auditability
Any updates on this feature?
This is what I have so far: fstadt@e9321b5
It's a WIP version where any tool call is paused/withheld and a validation button is displayed. When the validation button is clicked nothing happens though.
I have no experience with react or tenstack and was struggling to understand the architecture. I also rebased it on the current master today without paying a lot of attention to details. Thus, it might not make a lot of sense - I was trying to play around a bit and understand how things are working before making a "proper" shot at it.
Still gonna share it here, maybe it's useful in some way or someone can point me in the right direction. I could even direct some resources at work into contributing to this since this feature will be pretty important to us, but none of us have experience with react sadly :/
Reacted by César García Cabeza- marked [Enhancement]: Cancel/Decline tool run button #10450 as a duplicate of this issue
on Nov 11, 2025 This is what I have so far: fstadt@e9321b5
It's a WIP version where any tool call is paused/withheld and a validation button is displayed. When the validation button is clicked nothing happens though.
I have no experience with react or tenstack and was struggling to understand the architecture. I also rebased it on the current master today without paying a lot of attention to details. Thus, it might not make a lot of sense - I was trying to play around a bit and understand how things are working before making a "proper" shot at it.
Still gonna share it here, maybe it's useful in some way or someone can point me in the right direction. I could even direct some resources at work into contributing to this since this feature will be pretty important to us, but none of us have experience with react sadly :/
Thanks for this contribution! I’m currently using your fork with the elicitation support feature, and it’s a game changer. Because of LibreChat’s limitations, HITL wasn’t possible before, which is essential for production-sensitive use cases. Thanks again. @danny-avila, I believe this should be prioritized if possible.
Reacted by Animesh Sahu and Joel HirzelReacted by Animesh SahuWatching thread - manually approving MCPs is a frank must when dealing with sensitive data.
Reacted by Red5d, Animesh Sahu and M. R.- marked [Enhancement] Able to make agent wait for user input in agent-chaining when mentioned #7510 as a duplicate of this issue
on Dec 26, 2025 That would be very good
FYI, this has been picked up by Danny, these PRs are related (in order)
- 🛡️ feat: First-class HITL & permissions surface agents#134
- 🪝 feat: HITL Tool Approval Scaffolding (Slice A) #12938
- An as-of-yet not created third PR to use latest tag (or minimum, v3.1.78) from
agents
Reacted by Joel HirzelReacted by Animesh Sahu, privat655 and Joel Hirzel
What features would you like to see added?
An ability to let Agent ask user before making tool call, especially MCP tool calls.
More details
Sometime tools can mutate data. In such cases, it's better to get user approval before making a MCP tool call.
This is also recommended in MCP guidelines:
https://spec.modelcontextprotocol.io/specification/2024-11-05/#key-principles
Which components are impacted by your request?
UI
Pictures
This is how Claude Desktop does it:
Code of Conduct