Issue Station
Sign In
Tools hereToolbox

hermes - 💡(How to fix) Fix feat(security): Add first-invoke approval for MCP server tools [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#16462•Fetched 2026-04-28 06:53:09
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
fr33d3m0nfr33d3m0n
Participants
fr33d3m0nfr33d3m0n
Timeline (top)
labeled ×4subscribed ×1

When a user adds an MCP server via hermes mcp add, the server's tools are dynamically registered in the tool registry and become immediately callable by the LLM. There is currently no approval step between tool discovery and first invocation — the LLM can call any MCP tool without human confirmation.

This contrasts with the terminal tool, where DANGEROUS_PATTERNS and the approval system gate execution. MCP tools bypass this entirely because they go through a different dispatch path.

Root Cause

This contrasts with the terminal tool, where DANGEROUS_PATTERNS and the approval system gate execution. MCP tools bypass this entirely because they go through a different dispatch path.

Fix Action

Fix / Workaround

This contrasts with the terminal tool, where DANGEROUS_PATTERNS and the approval system gate execution. MCP tools bypass this entirely because they go through a different dispatch path.

  1. Makes tool exposure visible: Users see exactly what capabilities a new MCP server has before any tool runs

  2. Matches existing patterns: Similar to how the terminal approval system works for dangerous commands

  3. Low friction: Only triggers once per (server, tool) pair per session — subsequent calls are automatic

  4. Consistent with SECURITY.md: Section 2 notes MCP servers receive "lower trust" than installed skills. The current implementation doesn't reflect this trust distinction in the dispatch path.

  5. Track (server_id, tool_name) pairs in a session-scoped approved set (similar to _session_approved in tools/approval.py)

  6. Before dispatching an MCP tool call, check if the pair is approved

  7. If not, invoke the same approval callback mechanism used by the terminal tool

  8. Store approval at "server" scope (approve one tool → option to approve all tools from that server)

Code Example

User: hermes mcp add some-server
→ MCP client connects
→ Server advertises tools (e.g., "run_query", "send_email", "execute_code")
→ Tools registered in global tool registry
→ LLM can immediately call any of these tools
→ No approval prompt shown to user

---

User: hermes mcp add some-server
→ MCP client connects  
→ Server advertises tools
→ Tools registered as "pending first approval"
→ First call to each (server_id, tool_name) pair triggers approval prompt:
   "MCP server 'some-server' wants to execute tool 'run_query' for the first time.
    [Approve once] [Approve for this server] [Deny]"
→ After approval, subsequent calls to the same (server, tool) pair proceed without prompt
→ Approval state stored per-session (reset on /new)
RAW_BUFFERClick to expand / collapse

Summary

When a user adds an MCP server via hermes mcp add, the server's tools are dynamically registered in the tool registry and become immediately callable by the LLM. There is currently no approval step between tool discovery and first invocation — the LLM can call any MCP tool without human confirmation.

This contrasts with the terminal tool, where DANGEROUS_PATTERNS and the approval system gate execution. MCP tools bypass this entirely because they go through a different dispatch path.

Current Behavior

User: hermes mcp add some-server
→ MCP client connects
→ Server advertises tools (e.g., "run_query", "send_email", "execute_code")
→ Tools registered in global tool registry
→ LLM can immediately call any of these tools
→ No approval prompt shown to user

Proposed Behavior

User: hermes mcp add some-server
→ MCP client connects  
→ Server advertises tools
→ Tools registered as "pending first approval"
→ First call to each (server_id, tool_name) pair triggers approval prompt:
   "MCP server 'some-server' wants to execute tool 'run_query' for the first time.
    [Approve once] [Approve for this server] [Deny]"
→ After approval, subsequent calls to the same (server, tool) pair proceed without prompt
→ Approval state stored per-session (reset on /new)

Rationale

MCP servers are a rapidly growing ecosystem. Users may add servers recommended by third parties without fully understanding what tools they expose. A first-invoke approval step:

  1. Makes tool exposure visible: Users see exactly what capabilities a new MCP server has before any tool runs
  2. Matches existing patterns: Similar to how the terminal approval system works for dangerous commands
  3. Low friction: Only triggers once per (server, tool) pair per session — subsequent calls are automatic
  4. Consistent with SECURITY.md: Section 2 notes MCP servers receive "lower trust" than installed skills. The current implementation doesn't reflect this trust distinction in the dispatch path.

Implementation Suggestion

  1. Track (server_id, tool_name) pairs in a session-scoped approved set (similar to _session_approved in tools/approval.py)
  2. Before dispatching an MCP tool call, check if the pair is approved
  3. If not, invoke the same approval callback mechanism used by the terminal tool
  4. Store approval at "server" scope (approve one tool → option to approve all tools from that server)

References

  • tools/mcp_tool.py — MCP client and tool registration
  • tools/approval.py:308-310 — session-scoped approval state pattern
  • SECURITY.md:37-38 — MCP servers documented as "lower trust" than skills

extent analysis

TL;DR

Implement a first-invoke approval step for MCP tools to ensure users are aware of the capabilities exposed by newly added servers.

Guidance

  • Introduce a session-scoped approved set to track (server_id, tool_name) pairs, similar to the pattern in tools/approval.py.
  • Before dispatching an MCP tool call, check if the pair is approved; if not, invoke the approval callback mechanism used by the terminal tool.
  • Store approval at the "server" scope, allowing users to approve all tools from a server after approving one.
  • Update the hermes mcp add flow to register tools as "pending first approval" and trigger the approval prompt on the first call to each tool.

Example

# Pseudo-code example of the approval check
def dispatch_mcp_tool(server_id, tool_name):
    if (server_id, tool_name) not in session_approved:
        # Invoke approval callback mechanism
        approve_tool(server_id, tool_name)
    # Proceed with tool execution

Notes

The implementation should consider the existing approval system for terminal tools and the "lower trust" designation for MCP servers in SECURITY.md. The approval state should be stored per-session and reset on /new.

Recommendation

Apply the workaround by implementing the first-invoke approval step, as it aligns with the existing security patterns and provides a clear visibility of tool exposure to users.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#inference speed#output truncation#response parsing#generation error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix feat(security): Add first-invoke approval for MCP server tools [1 participants]