For agent builders
Post from your agent
Point it at the hosted MCP server and it gets five tools, six platforms and a sandbox to make its mistakes in.
MCP endpoint
Streamable HTTP.
Auth, either header
- Authorization: Bearer yp_secret_…
- x-api-key: yp_secret_…
The same API key as the REST API.
The five tools
list_connections
The accounts and channels available, with their slugs.
create_post
Posts text to connectionSlugs[]: now, at scheduledFor, into the queue, or as a draft. Takes tags, thread, firstComment and rewrite too. Returns a result per connection.
list_posts
Recent posts, newest first, with an optional status filter, tag filter and limit.
get_post
One post by postId, with its status, permalink and the newest numbers read off its platform.
cancel_scheduled_post
Cancels a scheduled post that has not gone out yet.
Tool arguments use the same camelCase names as the JSON endpoints: text, connectionSlugs, scheduledFor, postId, status, limit. One connection failing comes back as a failed item rather than a tool error, so an agent can say which platform bounced and carry on. get_post carries metrics.latest, so an agent can report how a post did; the wider analytics, a window of totals and a per-day series, is GET /analytics over REST. The full behaviour is on the MCP docs page.
Five tool definitions fit in a system prompt and stay there. An agent reads them once, at connect time, and from then on knows the whole product: list what it can post to, post, look up what it posted, cancel something scheduled. No discovery step, no search_tools call to spend a turn on, and no chance of picking the wrong one of forty near-identical endpoints. When an agent needs more than five tools, it reads the OpenAPI spec or calls the REST endpoints directly.
Connect a client
Connect with a login
No key to paste
In claude.ai, add https://api.yeetpost.com/api/v2/mcp as a custom connector and leave the key field empty. It discovers the rest on its own, opens a consent screen in your browser, and asks you to sign in to yeetpost, pick whether it reaches your whole account or one profile, and pick live or test. Approve and it is connected.
That is OAuth 2.1 underneath, with yeetpost as the authorization server: the client discovers it, registers itself, and gets a token good for an hour on a refresh token that rotates. What comes out is a grant, and a grant behaves like a key with the same two scopes: a profile grant sees that customer only, a test grant reaches sandbox connections only, and it gets its own 60 requests a minute. The apps you approved are listed on the MCP page in the console, and revoking one there stops its next request.
Keys are not going anywhere. A client that can hold one, Claude Code and Cursor included, should use one: it is pasted into a machine with no browser to open, and it is scoped and rotated without a consent screen. The flow is written out on the MCP docs page.
Otherwise every client wants the same three facts: the URL, a header, and a name. Grab a key from the API page first. The MCP page in the console prints all of these with your real key already in them.
The plugin installs the server, a yeetpost skill and a /yeetpost:quickstart command in one go. It reads the key from the environment, so export it first and restart Claude Code afterwards.
export YEETPOST_API_KEY=yp_secret_your_key_here
# then, in Claude Code:
/plugin marketplace add yeetpost/yeetpost
/plugin install yeetpost@yeetpostThe key goes in a header, so keep it out of anything you commit. Read it from the environment where your client supports that, and see the security checklist before you ship.
The CLI in three lines
Anything that can run a shell command can post. The CLI ships in the same npm package as the Node SDK.
npm i -g yeetpost
yeetpost login
yeetpost post "hello" --to all[email protected] is not on npm yet, so today the ways in are the MCP server above and the REST API. Ten commands, listed on the CLI page.
Sandbox and test keys
A sandbox connection takes posts, validates them, returns the shapes a real platform returns and fires the same webhooks, while publishing nothing, for free, without counting toward your plan.
A test key from settings starts yp_test_, sees sandbox connections only and refuses every other slug, so an agent that decides to post forty times cannot reach a real account.
Start the text with [fail] and the sandbox answers 422 platform_rejected, stores the post with that error and fires post.failed.
No MCP client? Use the REST API
MCP is a convenience, not a requirement. The same account posts to the same platforms over plain HTTP, which is often the shorter path for a framework that already has its own tool abstraction.
An Idempotency-Key makes a retry safe: a retried tool call should not post twice. Every endpoint is in the API reference, and the spec needs no key, so an agent can read it before it has one. Weighing this against Zernio's hosted MCP? The comparison puts both tool models side by side.