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 (prefix inklate_) 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.

  1. channels_list — where can I publish, and is each destination healthy?
  2. capabilities — what will each channel accept right now?
  3. posts_create — one call: content, channels (ids or provider names), and scheduled_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.
  4. posts_validate — the dry run: the same validation response, nothing persisted.
  5. posts_update — change anything, the schedule included (schedule: null returns a post to draft); posts_publish publishes an existing draft, safe to retry with an idempotency_key.
  6. 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 offset2026-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.

The same operations, three ways