Posta exposes four surfaces an agent (or an automation) can call into: an MCP server, a Claude Code skill, an n8n community node, and the public REST API. From a distance they look interchangeable — they all create posts, schedule them, and publish to the same eight networks. They are not interchangeable. Each was built for a different shape of agent, and picking wrong is the difference between an afternoon and a fortnight.
This is the decision guide we wish we’d had when we started shipping these. We’ll cover what each surface is, when to reach for it, and — most importantly — how to combine two or three in a production setup. Most real Posta deployments use exactly that combination.
The shapes, at a glance
- MCP server — interactive LLM agents (Claude Desktop, Cursor, custom MCP clients).
- Claude Code skill — terminal-driven agentic work, IDE-side workflows.
- n8n node — visual, branching pipelines triggered by non-LLM events (RSS, webhooks, schedules).
- REST API + webhooks — programmatic loops without an LLM in line, or fine control.
When MCP wins
MCP gives the model typed tool definitions it can introspect. The agent learns the right call without prompt-engineered API docs — every Posta capability (createPost, schedulePost, listAccounts, uploadMedia, getPostStatus) shows up in the tool list with a JSON Schema. It’s the right surface when:
- You’re building an interactive agent — the user (or another agent) talks to a model and the model decides what to do.
- You want the agent to discover Posta’s capabilities at runtime, not hard-code them in a prompt.
- You’re running a multi-step conversation where the agent needs to reach for several Posta tools across turns.
The install is one config-file entry — see the MCP server page for the exact JSON. Works in Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, Zed, and any custom MCP client.
When the Claude Code skill wins
The Posta Claude Code skill is a thin wrapper that turns terminal slash-commands into Posta calls. It’s the right surface when:
- You live in a terminal or IDE and don’t want to switch context to post.
- You want a focused, natural-language wrapper around the common posting workflows — draft, schedule, list, publish — rather than the full MCP tool set.
- You’re handing a small autonomy budget to a Claude Code agent and don’t want it to wander into the full Posta API.
You can run both the skill and the MCP server side-by-side. The skill is a UX shortcut; MCP is the underlying mechanism.
When n8n wins
The n8n community node turns every Posta endpoint into a typed, drag-and-drop n8n step. Drop it in next to RSS, OpenAI, HTTP, Schedule — wire them up. It’s the right surface when:
- Your trigger is non-LLM: an RSS feed, a webhook, a calendar event, a database change.
- You want visual branching and parallelism your team can read.
- You’re building a pipeline where an LLM is one step, not the orchestrator.
Examples: an RSS → LLM caption → Posta schedule flow, or a YouTube channel → Whisper highlight → Posta multi-platform fan-out. Fork any of the ready-made templates to get started.
When the REST API wins
The public REST API is the lowest common denominator — every other surface ultimately calls it. Reach for it directly when:
- There’s no LLM in your loop. A deterministic batch script that publishes a daily digest doesn’t need MCP.
- You need fine-grained control: idempotency keys, custom retry windows, per-call timeouts.
- You’re wrapping Posta in a framework that already has its own tool-calling abstraction (LangChain, CrewAI, Vercel AI SDK, Mastra — each has an integration guide).
And of course: HMAC-signed outbound webhooks are the closed-loop half of the REST API. The next post in this series covers them — for now, know that they’re what turns a one-shot script into an autonomous loop.
A decision tree
Is an LLM driving the decisions?
├─ No → REST API (or n8n if you want a visual pipeline)
└─ Yes
│
Is the agent interactive (chat-style, multi-turn)?
├─ No (one-shot batch / triggered run)
│ ├─ Trigger is non-LLM event (RSS, webhook, cron) → n8n
│ └─ Trigger is in a framework you already use → REST via that framework's tool wrapper
│
└─ Yes
│
Where does the agent live?
├─ Claude Desktop / Cursor / Windsurf / VS Code / Zed → MCP
├─ Terminal / Claude Code → Claude Code skill (+ MCP)
└─ Custom multi-agent framework → MCP via the framework's MCP adapterReal-world combinations
In practice, every production setup we’ve seen combines at least two surfaces. The patterns:
- n8n + REST. The default for content pipelines — n8n watches a trigger, an LLM step drafts a caption, the Posta node schedules. The "node" is REST under the hood.
- MCP + webhooks. The default for interactive bots — Claude calls Posta tools to schedule, then HMAC webhooks fire a separate handler when the post goes live. See the autonomous bot tutorial.
- Claude Code skill + MCP. The default for solo developers — slash-commands for the common cases, the MCP server for everything else, both pointed at the same token.
- n8n + MCP. n8n handles the trigger and orchestration, then calls into an MCP-capable agent for the parts where you want a model to make decisions (subject lines, image picks, posting cadence).
A common anti-pattern
Don’t use MCP for fully deterministic flows. If you know exactly which platforms, captions, and times every post should land at, you don’t need a model picking between tools — wire it through n8n or the REST API directly. MCP is a power tool; reach for it when the agent has to decide, not when it’s carrying out a known recipe.
Where to start
If you’re still unsure, follow the decision tree from your trigger. Most teams arrive at one of these starting points:
- You have an LLM agent already → install the MCP server.
- You have an n8n instance already → install the community node.
- You live in a terminal → install the Claude Code skill.
- You’re building from scratch → start with the agentic workflows guide.
All four surfaces share one token. Pick the one that matches your shape today; the others are ready when you grow into them. 14-day free trial, no credit card.