Help with MCP integration and request for temporary AI Assistant access

Questions
1

Hello n8n Community!

I am building an AI assistant called Miya using n8n hosted on Railway, Google Gemini, Telegram, and an external AiBox/MetaBox MCP server.

My existing workflow already includes an AI Agent connected to Gemini, an MCP Client Tool connected to the agent, Telegram integration, and memory nodes.

I need help troubleshooting the existing MCP integration.

1. How can I verify that the MCP Client Tool successfully discovers the tools available on the external MCP server?

2. Where can I inspect the discovered tool names, descriptions, and input parameter schemas?

3. What should I check if the MCP Client Tool is connected to the AI Agent but the agent does not use the tools?

4. How can I determine whether the issue is related to connectivity, authentication, tool discovery, or tool execution?

5. Is there a recommended way to identify which MCP tools can access or invoke built-in AI agents in AiBox/MetaBox?

I would also like to ask whether n8n could provide temporary free access to its AI Assistant, even for a limited period.

Unfortunately, I currently cannot afford a paid plan. Temporary access would help me troubleshoot and complete my existing workflow and bring Miya to a working state.

I am not asking to rebuild the workflow or change its architecture. I want to get the current setup working with the minimum necessary changes.

I would be grateful for any technical guidance or consideration of my request for temporary access.

Thank you for your time and support!

2

Hey @Mahmut1, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@jcuypers, @WolfgangB33r, @Pierre_R1 - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hey @Mahmut1 Welcome in,
You can check MCP discovery in your existing workflow. In MCP Client Tool, set Tools to Include to Selected and open the tool dropdown. Loading that list contacts the server, so a populated list confirms discovery worked for that request.

For names, descriptions and full input schemas, run npx @modelcontextprotocol/inspector locally and connect using the same endpoint, transport and authentication. The Tools tab lets you inspect and test a read-only tool. The Protocol and Network tabs show where connection, tools/list or tools/call fails. A successful local test doesn’t prove Railway can reach the same endpoint.

Back in n8n, select that tool, enable Return Intermediate Steps on the AI Agent, and test with a prompt explicitly asking it to use the tool. Check whether it actually calls it and what comes back, rather than relying on the agent’s final reply.

For AiBox/MetaBox’s built-in agents, we need the server’s tool descriptions or docs to identify the right invocation. Can you share those, your n8n version and any error, with credentials removed?

You don’t need the Assistant for these checks. Current self-hosted Community supports n8n Assistant with your own model account and a required sandbox. That avoids needing a paid n8n plan, but model and sandbox costs may still apply; it isn’t temporary free usage.

4

Hi Deepankar,

Thank you for taking the time to help me!

I’m working with n8n on Railway using only my Android phone, so I need to make the checks through the mobile browser.

My goal is to connect the MCP tools to my existing n8n workflow and get the AI agent working reliably. We previously encountered Groq errors related to oversized requests, but I want to verify the MCP tool discovery and actual tool calls before making further changes.

I’ll check the MCP Client Tool settings and look for the available tools. Then I’ll enable “Return Intermediate Steps” in the AI Agent and test an explicit tool call.

Could you please clarify one thing: should I perform these checks in my existing Telegram workflow, or in the separate workflow I created for managing n8n through its API?

I’ll share my n8n version and any relevant error messages once I can access them. I will remove all credentials and secrets before sharing anything.

Thanks again for your guidance!

сб, 17 окт. 2026 г., 01:54 Deepankar <notifications@n8n.discoursemail.com>:

5

On Android the editor is the same UI as desktop, just laid out for a narrow screen, so you can do the check in the mobile browser. Open the MCP Client Tool node, set Tools to Include to Selected, then open the tool dropdown: that dropdown is what calls tools/list on your AiBox/MetaBox server, so if your tools appear with names and parameter fields, discovery and auth are fine and the remaining work is on the agent side. If it comes back empty or errors, the problem is before the agent — endpoint, transport header, or the server rejecting the request — not the prompt.

On the earlier Groq oversized-request errors: every tool schema is sent with every LLM call, so a server exposing many or large tools plus a long memory window can exceed the context limit even for a one-line message. Two cheap checks: shorten the memory node window, and load only the two or three tools that call actually needs via Tools to Include. It is also worth logging the tool arguments and output size once — a single tool returning a huge payload is often what makes the next request fail.

6

I appreciate it, @Mahmut1
I would suggest to do them in the existing Telegram workflow, since that’s where the MCP Client Tool sits on the agent. The API-management workflow doesn’t touch it.

The inspector step from my earlier reply won’t run on a phone, so use a standalone MCP Client node instead (not the Tool version), in a new blank workflow so the Telegram one stays untouched. Give it the same endpoint URL, transport and auth as your MCP Client Tool, pick a tool from its Tool dropdown, set Input Mode to Manual to see that tool’s parameters, and run the node. You get the server’s raw result or the exact error with the agent out of the picture. If that works but the agent still won’t call the tool, the problem is on the agent side, not the MCP server.

7

Hi Deepankar and everyone,

Thank you very much for your time, support, and detailed explanations! I really appreciate your help and the effort you’ve taken to guide me through this.

I’m working from an Android phone, so I’ll follow your instructions step by step, starting with checking tool discovery in my existing Telegram workflow. I’ll keep the current workflow untouched while testing.

Your guidance has helped me understand how to approach the MCP issue more systematically instead of changing settings blindly.

Thank you again for your patience and support. I’ll share the results once I complete the checks.

Best regards,
Mahmut

сб, 17 окт. 2026 г., 03:22 Deepankar <notifications@n8n.discoursemail.com>:

8

Hi HomelabAgent,

Thank you very much for your helpful and detailed explanation!

Your advice about checking MCP tool discovery and limiting the number of tools and memory size gave me a much clearer understanding of what might be causing the oversized Groq requests.

I’ll start by checking the MCP Client Tool in my existing Telegram workflow, without changing the workflow structure. I’m working from an Android phone, so your practical guidance is especially helpful.

I really appreciate you taking the time to help me troubleshoot this. Thank you for your support!

Best regards,
Mahmut

сб, 17 окт. 2026 г., 03:29 Махмут <mbilalev0@gmail.com>:

9

:high_voltage: MCP LIFECYCLE DEBUGGING: RESOLVING SCHEMA DISCOVERY & EXECUTION DRIFT IN PRODUCTION AGENTS

Hi @Mahmut1,

Isolating Model Context Protocol (MCP) tool-handling errors inside self-hosted environments (like n8n on Railway) requires diving into strict transport layers and schema validation checkpoints. When an AI Agent (Gemini) silently bypasses discovered MCP tools, it is rarely a prompt failure—it is almost always an unhandled JSON-RPC handshake mismatch or container-level networking isolation.

Here is a systematic, production-grade debugging matrix to isolate and resolve your 5 core checkpoints:

:one: Verifying Tool Discovery & Inspecting Parameter Schemas (Questions 1 & 2)

  • The Execution Log Hack: n8n’s UI abstracts the raw MCP tools/list handshake. To explicitly audit the discovered tool names, descriptions, and input schemas, execute the workflow in your editor and immediately inspect the “JSON Output” or “Execution Data” tab of your MCP Client Tool node before it hits the AI Agent node.
  • Look for the tools array block. If that array is completely blank or missing, your n8n instance is failing the initial JSON-RPC compilation step over your transport layer (SSE or Stdio).

:two: Why the Agent Silently Bypasses Discovered Tools (Question 3 & 4)

  • Context Token Truncation: If Gemini refuses to invoke discovered tools, your system is likely hitting context anomalies. Raw MCP schema payloads can be massively verbose. When multi-agent configurations or Chat Memory nodes bloat the context window during a multi-turn conversation, the LLM drops tool-calling priority. Ensure you apply strict token truncation or use a dedicated memory management strategy.
  • Non-Deterministic Prompt Boundaries: Ensure your AI Agent node has its System Prompt explicitly hardened to force tool validation. If your prompt doesn’t strictly instruct the model to look at external schemas, probabilistic models like Gemini will default to a standard text response, skipping the tool layer entirely.

:three: Connectivity vs. Authentication Triaging

  • Railway Environment Variables: Check your Railway service logs. If n8n runs in an isolated container network, it might hit an ETIMEDOUT error when polling the external AiBox/MetaBox SSE endpoint. Ensure N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true is set and verify that your bearer authentication tokens or custom headers are natively passed inside the MCP Client node’s connection payload.
  • Ingestion Durability: To protect your intake gateways when Telegram users bombard Miya with multiple concurrent execution triggers, ensure you wrap your database write layer in strict structural guardrails. In my self-hosted Python/n8n clusters handling 1.2M+ daily vectors, I deploy native Redis lock primitives (INCR + TTL gates) as atomic idempotency boundaries directly within the data transit paths to prevent parallel execution race conditions or duplicate ledger mutations in under 45ms.

:four: Identifying Built-in AI Agent Invocation (Question 5)

  • Inspect the raw JSON-RPC response from your MetaBox server. Tools capable of routing to upstream sub-agents usually require a strict metadata key or an explicit parameter block like agent_routing_target inside their input properties. If this is missing from the discovered schema array, the core agent cannot trigger it.

:light_bulb: Regarding your AI Assistant Access Request:
If you are running n8n self-hosted on Railway, you don’t actually need a paid cloud plan to leverage advanced assistant mechanics! You can fully achieve this locally or inside your current tier by combining the native n8n Advanced AI nodes with open-weight models (like Llama/Qwen variants) running on low-cost open infrastructure (OpenRouter or Nebius) utilizing rigid Pydantic validation schemas to guarantee output determinism.

:laptop: You can directly audit how I manage these containerized multi-agent environments, strict state-locking sub-graphs, and validation schemas straight from my verified repository:
:backhand_index_pointing_right: https://github.com

Drop a sanitized snippet of your raw execution JSON logs from the MCP Client node if the tool array is throwing a specific serialization exception—happy to break down the exact JSON-RPC schema fix to get Miya fully working.

10

Since you’re exploring MCP integration with AI agents, you may also find DeskVNC interesting. It provides an MCP interface for compatible AI agents to interact with existing VNC and RDP remote desktop sessions, including screenshots and mouse/keyboard interaction.

I’m associated with the DeskVNC project, and thought it might be relevant to your MCP exploration: GitHub - psmux/DeskVNC: Native VNC, RDP and SSH client for Windows, macOS and Linux. Pure-Rust protocol cores, Tauri 2. One host library for all three, plus an MCP control plane so an AI agent can drive remote desktops with human takeover. · GitHub