MCP Server Trigger example: expose 3 code tools to Claude Code / Cursor (JSON attached)

Built with n8n
1

I wanted a minimal, working example of the MCP Server Trigger, so here’s one you can import and adapt. It serves three Code Tool nodes over MCP:

  • word_count: words, characters and lines of a text
  • slugify: title → URL slug
  • days_between: days between two ISO dates (2026-01-01,2026-03-01 → 59)

Tested on n8n 2.43.5 (self-hosted, npm) with Claude Code 2.1.300.

Setup

  1. Import the attached JSON (Workflows → Import from File…).
  1. Activate the workflow and copy the trigger’s Production URL (on a local instance: http://localhost:5678/mcp/utility-tools).
  2. Connect a client. For Claude Code:
    claude mcp add --transport http n8n-tools http://localhost:5678/mcp/utility-tools
claude mcp list
    claude mcp list should show n8n-tools: … (HTTP) - ✔ Connected.

Results from a plain MCP client

tools: days_between, slugify, word_count
word_count("hello brave new world")   -> {"words":4,"characters":21,"lines":1}
slugify("Hello, Wörld! MCP & n8n")     -> hello-world-mcp-n8n
days_between("2026-01-01,2026-03-01")  -> 59

Notes

  • The Code Tool gets the model’s input as query and should return a string.
  • The tool description is what the model uses to decide how to call it, so I wrote each one with an input example.
  • The trigger has no auth in this example. Turn on Bearer or Header auth before exposing it beyond localhost, and pass the token with --header "Authorization: Bearer …".
  • The Test URL only works while the editor is listening; clients need the Production URL of the active workflow.

Happy to answer questions or adjust it. If anyone has a cleaner way to return structured JSON from a Code Tool to MCP clients, I’d like to see it.

More MCP + n8n setups and a free sample pack: MCP guides: install, secure and build MCP servers

1 個讚
2

One small thing I noticed with word_count: it might be worth clarifying what “characters” means.

For example, "👩‍💻".length is 5 in JavaScript, but it’s 3 code points and just 1 grapheme cluster. That difference could be confusing when an MCP client uses the result to enforce a text limit.

Maybe naming the count explicitly would be enough, or returning separate counts if the tool is meant for multilingual text.

I maintain a short reference explaining the different Unicode length measurements, in case it’s useful: