Plugin Hooks Not Triggering When Calling Virtual Server via MCP SSE Endpoint from n8n

[manu-jain-pointguardai]

Description
I'm experiencing an issue where custom security plugins are not triggering when tools are invoked through the MCP SSE endpoint (/servers/{id}/mcp) from n8n workflows, despite being properly configured and enabled in plugins/config.yaml.

Environment

1. Context Forge Version: Latest (Docker deployment)
2. Integration: n8n MCP Client node
3. Endpoint: /servers/{server-id}/mcp
4. Plugin Configuration:
5. Plugin: mode: "enforce", priority 60
6. Hooks registered: prompt_pre_fetch, prompt_post_fetch, tool_pre_invoke, tool_post_invoke

What Works

✅ Plugins fire correctly when calling tools via JSON-RPC /rpc endpoint (verified with test script)
✅ Plugins fire correctly when calling tools via custom CLI chatbot using the same /servers/{id}/mcp endpoint locally
✅ Plugin initialization logs show successful registration
✅ Virtual server is accessible and tools execute successfully

What Doesn't Work
❌ No plugin logs appear when invoking tools from n8n workflows
❌ No PlugIn inspecting INPUT or tool_pre_invoke logs
❌ Sensitive data (SSN, credit cards) passes through without redaction or blocking

Expected Behavior
When a tool is invoked via n8n → MCP Client → /servers/{id}/mcp, the plugins should:

• Intercept the request via tool_pre_invoke hook
• Inspect input for sensitive data (DLP) and prompt injection
• Redact or block violations based on policy
• Log all inspection activity

Actual Behavior
Tools execute successfully but plugin hooks are completely bypassed - no logs, no inspection, no security enforcement.

Investigation Results

• Verified plugin configuration is correct (works via /rpc and local chatbot)
• Confirmed same virtual server ID and endpoint path
• Checked Docker logs during n8n workflow execution - zero plugin activity
• Tested with both permissive and enforce modes - same result

Local Python chatbot calling the exact same endpoint shows plugins working perfectly

Questions

1. Does the MCP SSE endpoint (/servers/{id}/mcp) properly integrate with the plugin framework when accessed via external clients like n8n?
2. Are there specific headers or request formats required for plugins to trigger via the MCP endpoint?
3. Is there a known difference in how the plugin manager handles requests from the MCP SSE transport vs JSON-RPC?
4. Could there be a difference in how requests are processed when coming from external sources vs localhost?

Logs
When calling from n8n (no plugin activity):
2026-02-09T19:36:39 - mcp.server.lowlevel.server - INFO - Processing request of type ListToolsRequest2026-02-09T19:36:39 - mcp.server.streamable_http - INFO - Terminating session: None2026-02-09T19:36:39 - mcpgateway.services.structured_logger - INFO - [http_gateway] Request completed: POST /servers/93a6bd4ec36a4def82100960c4e468da/mcp - 200

When calling from local chatbot (plugins working):
2026-02-09T20:10:20 - plugins.{name}.{name} - INFO - {name} inspecting INPUT for tool 'google-sheets-get-patient-info'2026-02-09T20:10:20 - plugins.{name}.{name} - INFO - {name} INPUT result: blocked=False, modified=True2026-02-09T20:10:20 - plugins.{name}.{name}- INFO - {name} REDACTED input for tool 'google-sheets-get-patient-info'

Any guidance on troubleshooting this would be greatly appreciated!

[araujof]

@terylt did you see this?

@manu-jain-pointguardai if you haven't already, could you please open an issue for this?

[crivetimihai]

Hi @manu-jain-pointguardai, thanks for raising this. That looks like a regression candidate. Could you share the gateway version, the n8n MCP client config, and a minimal request log (especially /servers and tool-invoke events) so I can reproduce and validate plugin hook propagation?

[crivetimihai]

Hi @manu-jain-pointguardai, I've done some investigation into the code paths.

The plugin hook invocation code (tool_pre_invoke, tool_post_invoke) is present in both the /rpc and the SSE/streamable HTTP paths — the SSE endpoint internally routes tool calls through the same tool_service.invoke_tool() method that /rpc uses.

However, there are a few differences in the SSE path that could explain the behavior:

1. Plugin context propagation: When tool calls come through the SSE/streamable HTTP transport, the plugin context (local_contexts) may not be properly propagated from the session to the hook invocation. The REST tool path explicitly passes local_contexts=context_table, but the MCP tool path passes local_contexts=None initially.

2. Request header differences: The SSE path reconstructs headers when routing to the internal /rpc endpoint, which may not preserve custom headers from the original client request. If your plugin relies on specific request headers for initialization or context, these may be lost.

3. Plugin manager instance: If the plugin manager isn't properly initialized in the SSE session's request context, hooks won't fire even though the code to call them exists.

Debugging steps:

• Enable LOG_LEVEL=DEBUG and look for "plugin" or "hook" entries during an n8n request
• Check if the n8n MCP client uses a different session initialization flow that might skip plugin setup
• Compare the request headers from n8n vs. your local chatbot — the local chatbot may be sending different headers that trigger proper plugin initialization

If you can share the gateway version, n8n MCP client config, and request logs as I've asked, we can narrow this down further. Filing an issue would also help track this to resolution.

[itxashancode]

We have prior comments: crivetimihai says plugin hook invocation code is present in both /rpc and SSE/streamable HTTP paths - the SSE endpoint internally routes tool calls through same tool_service.... So they suspect maybe something else. n8n MCP client might not be sending proper MCP protocol init? Perhaps need to make sure the SSE connection is established correctly and that tool calls are sent as MCP messages (JSON-RPC over SSE). The plugin hooks might be tied to the internal tool service but only invoked when the request goes through the MCP dispatcher that wraps tool_service with plugin hooks. If n8n is not doing the MCP initialize handshake, maybe the server treats it as raw HTTP and bypasses plugin layer. Check logs for "MCP initialize" and "notifications/tools/list". If missing, plugin hooks won't fire because the request is treated as a plain HTTP POST to /servers/{id}/mcp? Act