Tools and permissions

OpenPost advertises operations through a small MCP surface rather than one tool per HTTP endpoint. The client can search the operation catalog, inspect an operation's input and output schema, and execute a selected operation.

Read and write access

Choose the narrowest scope that fits the job:

An omitted OAuth scope currently defaults to mcp:full; select mcp:read explicitly when you only need inspection. A developer token can use the same MCP scopes, or the existing cli:full scope. Token workspace access and MCP scope are separate: bind a token to one workspace when possible, then grant only the required scope.

Useful requests

Try these after connecting:

List my workspaces and tell me which one you are using.
Review this week's scheduled publications and flag anything missing media.
Show the connected accounts that can publish to LinkedIn.
Draft a launch post for the selected workspace, but do not schedule or publish it.

For a write-capable connection, state the boundary in the request: “Create the draft, then stop for my review.” Client confirmation is separate from OpenPost permissions and differs between clients. Verify the workspace, account, destination, timing, and final text before asking the assistant to schedule or publish.

Endpoint and troubleshooting

Use /mcp, not /api/v1/mcp. The server uses Streamable HTTP and bearer authentication. A 401 usually means the OAuth connection expired or the bearer token is wrong; reconnect the client or issue a new token. A 403 can mean the token lacks mcp:full, lacks the requested workspace, or the operation is unavailable for the account or plan. If a self-hosted client cannot connect, check public HTTPS, reverse-proxy POST support, and the OAuth discovery paths under /.well-known/.