Connect with MCP

Connect your assistant to OpenPost, choose its permissions, and verify read access before making changes. MCP can inspect posts, variants, schedules, accounts, media, and delivery results. Full access also permits drafts, publishing, and supported comment actions.

Use Chat assistants or Coding assistants for your client's exact configuration.

OpenPost offers two MCP endpoints. They use the same authentication, scopes, workspace checks, validation, and operation behavior.

Choose an endpoint

Direct tools

Use the default endpoint for most clients:

https://app.openpo.st/mcp

It lists each available operation as a separate tool. An assistant can call tools such as list_workspaces, list_posts, or create_post with the operation's own input schema.

Choose this endpoint when the client handles a full tool catalog well. It gives the assistant the clearest tool names and schemas at the start of the session.

Compact tools

Use the compact endpoint when the client has a strict tool or context limit:

https://app.openpo.st/mcp/code

It exposes a small routing set:

• search_operations finds matching OpenPost operations and returns their schemas and safety information.
• query_operation runs only read-only operations.
• execute_operation runs only operations that change state or interact with an external service. Requires mcp:full.
• render_scheduler_widget renders structured OpenPost data in the ChatGPT Apps widget. Read-only; available with mcp:read.
• render_local_media_upload opens the device file picker for a workspace. Read-only; available with mcp:read. Its one-use upload ticket tool is app-only and requires mcp:full.

A read-only connection does not receive execute_operation or the upload ticket tool. Search results also exclude write operations. The server rejects an operation passed through the wrong execution tool.

The compact endpoint does not run model-written code. It reduces the initial tool list and still sends each request through OpenPost's typed operation handlers.

Self-hosted tool mode

Self-hosted operators can set OPENPOST_MCP_MODE to control the catalog at /mcp:

/mcp/code always uses the compact list. Changing the tool list does not change permissions.

Some clients cache tool definitions. Refresh the MCP server metadata or start a new session after changing endpoints or modes.

Sign in

Use browser OAuth when your client supports it. Otherwise create a developer token in Settings > Personal > Developer and store it in the client's secure authentication settings or environment. Never paste a token into a conversation or commit it to a config file.

OpenPost checks the token scope and workspace access for every MCP operation. The client may add its own approval prompt, but client approval does not replace OpenPost permissions.

Choose a scope

OpenPost defaults an OAuth request with no scope to mcp:full. Select mcp:read explicitly for reviews and audits.

Bind the connection or developer token to one workspace when the assistant does not need access to every workspace. A workspace-bound token cannot list or target another workspace.

Review before publishing

For write tasks, tell the assistant where to stop:

Create an unpublished draft for my review. Do not schedule or publish it.

Before publishing, check the workspace, destination accounts, text, media, and time. A scheduled or queued Post is not published. Ask the assistant to inspect the Post's variants and lifecycle events when delivery is partial or fails.

Recent MCP calls appear under Settings > Personal > Developer access. Use that activity to identify the client, tool, workspace, result, and failure reason.

Use remote HTTP when the client can reach your OpenPost instance. Use the local bridge when a desktop client can reach the instance from your computer but the client's cloud service cannot.

Connect a self-hosted instance

Public HTTPS

Replace the Hosted origin with your own origin and keep the MCP path:

https://openpost.example.com/mcp

Use /mcp/code instead when you need the compact tool list. Your reverse proxy must serve the instance over HTTPS, preserve authorization headers, and forward POST requests to OpenPost. OAuth-aware clients also use the discovery paths under /.well-known/.

Private instance and local bridge

Install the CLI and openpost-mcp bridge:

curl -fsSL https://raw.githubusercontent.com/getopenpost/openpost/main/scripts/install-cli.sh | sh -s -- --with-mcp

Sign in to the instance with a named CLI profile:

openpost --profile local auth login https://openpost.internal.example

Configure the MCP client to launch the bridge with the same profile:

{
  "mcpServers": {
    "openpost": {
      "command": "openpost-mcp",
      "args": ["--profile", "local"]
    }
  }
}

The bridge reads the saved CLI profile and token, then forwards MCP messages to the instance's /mcp endpoint. The client starts the process, so you do not need to keep a separate terminal open.

If the client cannot find the command, replace openpost-mcp with the path returned by:

command -v openpost-mcp

Cloud clients

A cloud client cannot use localhost or a private LAN address on your computer. Give it a public HTTPS instance if the product supports remote custom MCP servers. A local bridge works only when the MCP process runs on a machine that can reach OpenPost.

Use the setup page for your client to confirm its transport and configuration format. Do not configure the remote endpoint and the local bridge under the same server name.

Verify the connection

Ask the assistant:

List my OpenPost workspaces.

Name a returned workspace and request its schedule without changes. This checks the account, workspace, and read permissions. Then use Upload media or Tasks and troubleshooting.