MCP
Inklate's Model Context Protocol server — one Streamable HTTP endpoint that lets Claude or any MCP client discover channels, create and schedule posts in one call, and measure what shipped.
Inklate exposes a Model Context Protocol server, so any MCP client — Claude Code, Claude Desktop, Cursor, your own agent — can operate every social channel you have connected. The agent calls the same guarded procedures the dashboard calls, so an agent and a person with the same permissions can do exactly the same things, and neither can do more.
- Transport: Streamable HTTP
- URL:
https://api.inklate.com/mcp - Local dev:
http://localhost:3000/mcp - Auth:
Authorization: Bearer <token>— an Organization API key (prefixinklate_) or an OAuth 2.1 access token
Connect in one command
claude mcp add inklate https://api.inklate.com/mcp -t http \
-H "Authorization: Bearer inklate_XXXXXXXX"Full client configurations, and the OAuth flow if you would rather not paste a key, are on Connect a client.
What the tools are shaped like
The catalog is deliberately thin and CRUD-shaped: small tools an agent composes, not one do-everything tool. A typical session runs the same path a person does.
channels_list— where can I publish, and is each destination healthy?capabilities— what will each channel accept right now?posts_create— one call: content,channels(ids or provider names), andscheduled_at(omit for a draft, a future instant to book it,"now"to publish). The response carries per-channel validation —ready, errors with machine fixes, warnings, applied autofixes.posts_validate— the dry run: the same validation response, nothing persisted.posts_update— change anything, the schedule included (schedule: nullreturns a post to draft);posts_publishpublishes an existing draft, safe to retry with anidempotency_key.posts_get— the post, its validation, and each channel’s live publish result (status, external id, URL, last error) — poll it after publishing.
See Available tools for the full list, and each tool’s own page for its exact input.
Scheduling and publishing are durable background operations. Drafts and posts_validate work on
their own, but a write that arms (scheduled_at set, or posts_publish) fails loudly rather than
silently when the durable-execution layer isn’t running — a scheduled ship is never quietly
dropped.
Timestamps
Every timestamp is ISO-8601 with an offset — 2026-07-14T09:00:00-07:00 or …Z. A naive
local time is rejected with a corrective error, because a server cannot guess which timezone
“9am” meant. Resolve the user’s timezone in your client and send the offset.
The scheduled_at field also accepts a relative shorthand anchored to the server clock: 30m,
2h, 3d, 1w — plus "now" for an immediate publish. Read filters (since, from, to)
stay strict ISO.
Errors are instructions
A refusal comes back prefixed with its code — NOT_FOUND, FORBIDDEN, CONFLICT,
TOO_MANY_REQUESTS, BAD_REQUEST — and a message written to be acted on rather than logged,
with machine slugs riding inline ([reason:not_ready]). A publish blocked by policy says which
rule blocked it; an over-length post says by how much and offers a fix. Read the message before
retrying — the full machine catalog is on Errors and fixes.