Use the MCP server with n8n

n8n workflows can use the messaging API in two ways:

• AI Agent with MCP tools. An n8n AI Agent connects to the MCP server through the MCP Client Tool node and decides which messaging tool to call.
• Plain nodes. An HTTP Request node calls the REST API directly, and a Webhook node receives delivery statuses. No AI decides anything; every send is a step you designed.

Use the first for assistants that answer questions or draft messages, and the second for anything that must send the same way every time, such as OTPs and order notifications. n8n's own documentation is the reference for its nodes: MCP Client Tool, HTTP Request and Webhook.

Option 1: AI Agent with the MCP Client Tool#

1. Add an AI Agent node to your workflow, with a chat model.
2. Attach an MCP Client Tool node to the agent's tool input.
3. Set the endpoint to https://mcp.broadnet.me/mcp. If the node offers a transport choice, choose HTTP Streamable: the server uses MCP Streamable HTTP. Older n8n versions offer only an SSE endpoint; update n8n if yours does.
4. Set Authentication to Bearer Auth and create a credential holding your key. n8n stores credentials encrypted, so the key does not appear in the exported workflow.
5. Set Tools to Include to Selected and pick only the tools this agent needs. Leaving it on All gives the agent every send tool on your account.

Keep unattended agents safe#

An n8n workflow usually runs without a person watching, so nobody approves each tool call as they would in Claude Code or Cursor. Before you activate one:

• Give the agent read tools only (templates, delivery reports) unless sending is its job.
• For an agent that sends, limit it to one channel's send tool, and test it against your own verified numbers.
• Put a fixed step in front of sends that need a person's sign-off, for example a draft that a team member approves before an HTTP Request node sends it.
• Use a temporary key while testing, and a permanent key only for a reviewed workflow.

The full list of safety rules is on the MCP server page.

Option 2: REST API with HTTP Request and Webhook nodes#

Send a message#

Add an HTTP Request node:

{
  "senderId": "OmniDemo",
  "destinationNumber": "{{ $json.phone }}",
  "message": "Your OmniDemo code is {{ $json.code }}",
  "messageType": "TEXT"
}

The response is the message ID. Store it with the record that triggered the send, so you can match delivery statuses to it later. Other channels follow the same pattern; take the path and fields from the channel's page or the OpenAPI spec. Some send operations, such as POST /whatsapp/message/sendbulk, take a multipart form body instead of JSON: in the HTTP Request node choose the form-data body type for those.

Receive delivery statuses#

1. Add a Webhook node with the HTTP method POST.
2. Activate the workflow and copy the node's production URL. (The test URL only works while you are listening for a test event in the editor.)
3. Send that URL to our team or your account admin to configure it as the webhook on your account. See Webhooks.
4. Send a test message to your own number and check that the execution appears.

Statuses arrive as SUBMITTED, SENT, DELIVERED, READ, FAILED and REJECTED, can arrive more than once and out of order, and their payload fields vary by channel. Follow the handler rules in Webhooks: store the event, answer quickly, and never send a message again from the webhook branch.

Next steps#

• MCP server: endpoint, keys and safe-use rules.
• Make and Zapier with webhooks: the same REST and webhook pattern in other automation tools.
• Errors and limits: which errors to retry in a workflow.