API reference · MCP

MCP Endpoint

POST /v1/mcp

Model Context Protocol JSON-RPC endpoint. PREFER `POST /mcp`: it is the canonical URL and now accepts either an API key or an OAuth access token, so there is no longer a reason to choose between two paths. This one is kept working for configs already pointing at it. The same tool registry covers publishing, scheduling, validation, media, notifications, comments, direct messages, engagement, profile and channel management, and analytics. See https://docs.postlake.dev/mcp for the full toolset and authentication options.

Request

Authenticate with a bearer API key. Agents calling over MCP authorise with OAuth instead and never handle the key.

curl -X POST https://api.postlake.dev/v1/mcp \
  -H "Authorization: Bearer $POSTLAKE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"…","method":"…","params":{},"id":"…"}'

Body

Field	Type	Required
`jsonrpc`	string	Yes
`method`	string	Yes
`params`	object	No
`id`	string or number or null	No

Response

Success (200).

Field	Type	Required
`jsonrpc`	string	Yes
`result`	object	No
`error`	object	No
`error.code`	integer	Yes
`error.message`	string	Yes
`error.data`	object	No
`id`	string or number or null	No

Example

{
  "jsonrpc": "…",
  "result": {},
  "error": {
    "code": 0,
    "message": "…",
    "data": {}
  },
  "id": "…"
}

Limits

Write operations are limited per account, and rate-limit responses include Retry-After. Do not automatically retry a write unless this operation explicitly documents idempotency.

Calling this from an agent

This operation is part of the REST surface. Agents working over the hosted MCP server reach the same product through tools instead, and authorise with OAuth so your API key is never pasted into a chat. See the MCP server.

Errors

Every failure uses one shape: a stable type, a granular code, the field at fault in param, and a plain-language fix. An agent can act on it without a person reading the message. See Errors and retries.

Check the result before retrying a write. Only operations that explicitly support idempotency can safely replay an Idempotency-Key.

Common questions

Is it safe to retry this call?

Do not automatically repeat a write after a timeout unless that endpoint explicitly documents idempotency. First read the resulting state; a second request could repeat the action.

What happens when it fails?

You get one error shape: a stable type, a granular code you can branch on, the offending field in param, and a fix written so an agent can correct itself rather than stop. Full list on Errors and retries.