I gave my social media scheduler an MCP server. Here's what I learned building it.

Annie Yang — Mon, 09 Nov 2026 00:35:39 +0000

Social media scheduling is the kind of task AI agents should be perfect at. It's structured (a caption, some media, a list of accounts, a time), it's repetitive, and the rules are knowable - character limits, aspect ratios, which platform takes what. The only thing missing was a way for the agent to actually do it instead of just drafting captions I'd still have to paste somewhere.

So when I built Ampli, my social media scheduler, I didn't bolt an API on at the end. The MCP server is a first-class surface: anything a user can do in the app - bring their own media, schedule and publish to eight networks (TikTok, Instagram, Pinterest, LinkedIn, Threads, Facebook, YouTube, X), keep an ideas board, read analytics - an agent can do through tools.

Here's what building that actually involved, including the parts I got wrong first.

One behaviour, two surfaces

The decision that saved me the most pain: the MCP tools are not a separate implementation. They call the same v1 REST endpoints the app uses, with the same ownership checks and the same publishing validation. Some tools add defaults, combine calls, or trim the response for an agent-sized context window, but there is exactly one place where "can this user post this to this account?" is answered.

If you're adding MCP to an existing product, I'd strongly recommend this shape over a parallel agent-only backend. Every bug you fix, you fix once, and the agent can never become a backdoor around your own rules.

The server itself is remote Streamable HTTP at https://www.useampli.com/api/mcp, stateless, POST-only. (That last part confuses every health checker on the internet: a GET returns 405, which is correct behaviour for this transport, and at least one directory still lists us as "Unhealthy" because its checker knocks with GET and no credentials. If you ship a remote server, expect this mail.)

Auth: OAuth for agents, keys for scripts

Remote MCP forced the auth question early, and the answer turned out to be "both":

OAuth 2.1 with PKCE and dynamic client registration for clients that support it (Claude.ai, Claude Desktop, ChatGPT, and others). The server publishes the standard discovery documents (/.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource), registration lives at /api/oauth/register, and the user just clicks Authorize - no key to copy, paste, or leak into a config file.
Personal API keys for everything else: scripts, REST calls, and stdio-only clients. For those, there's a small bridge package so a JSON-config client can still connect:

{
  "mcpServers": {
    "ampli": {
      "command": "npx",
      "args": ["-y", "viralfarm-mcp@latest"],
      "env": { "VIRALFARM_API_KEY": "vf_your_key" }
    }
  }
}

Or with Claude Code, it's one line:

claude mcp add --transport http ampli https://www.useampli.com/api/mcp \
  --header "Authorization: Bearer vf_your_key"

One design detail I'm happy with: completing the OAuth flow mints an API key behind the scenes, named after the client (you'll see something like "Claude (OAuth)" in Settings → API Keys). It counts toward the plan's key allowance and can be revoked like any other key. One credential model to reason about, one revocation list, no special OAuth-token storage to audit later.

And one I'm phasing out: we briefly accepted keys in a ?key= URL parameter because some early clients could do nothing else. URLs get logged, screenshotted, and shared - keys don't belong in them. Newer keys are refused in URLs entirely, and every request that still tries gets a 401 explaining how to reconnect properly.

Designing tools for an agent, not a human

This was the real work. Three lessons:

1. "Success" is not "published." Our create-post response returns success: true when the request was accepted and the post object exists. Whether it actually went live is a separate field - publishNow.outcome on the create, outcome on every post read. An agent that reports "posted!" off the success flag will eventually lie to its user, confidently. If your tools wrap anything asynchronous or fallible, give the agent an explicit outcome to read, and say so in the tool description.

2. Agents retry. Make retries safe. POST /posts (and post creation through MCP) accepts an Idempotency-Key. The key is written by the same database insert that creates the post, so whatever fails afterwards - a timeout, a publish step that dies mid-flight - a retry with the same key returns the original post, never a duplicate. Same key with a different body is a 422; same key while the first attempt is still running is a 409. An agent that gets nervous and hammers your endpoint should produce exactly one scheduled post.

3. Teach the rules before the post, not after. Every platform rejects differently - title length here, a TikTok privacy option there. Instead of letting the agent discover this from failed posts, there's a per-account publishing-options call that returns the limits and fields that account actually accepts (Pinterest boards included). The agent reads the rules, builds a valid request, and validation errors - when they still happen - come back in plain language with the specific field named and one line per platform rule, so the agent can fix the request instead of apologising.

What it looks like in practice

With the connector added, "take these three photos, write a caption for each channel, and schedule them across my accounts for next week" is a single instruction. The agent lists the connected accounts, reads each one's publishing options, uploads the media, creates the posts with per-platform overrides, and reads back the outcome of each one. It's in the API & MCP reference if you want the full tool-by-tool picture.

If you're adding MCP to your product

Start with the REST API you already trust and wrap it - don't fork your business logic. Do OAuth properly (PKCE + dynamic registration) so the big clients connect with a click, but keep API keys for the long tail. Then spend your remaining effort where it actually matters: outcome fields an agent can trust, idempotency so retries are free, and errors written for a reader that will act on them literally.