MCP server
Postlyra runs an MCP server at:
https://mcp.postlyra.comPoint an MCP client at it and the client can read your brand's voice and pillars, push content ideas, browse the idea queue, and write drafts into Planning. Claude Code and the CLI use an API token. Claude.ai and ChatGPT connect through OAuth, which means you approve them on a Postlyra screen instead of pasting anything.
It is the same engine the REST API and the CLI use, so dedup, idempotency and brand scoping behave identically whichever path you take.
Why you would use it
The CLI mines a whole time window blindly: every commit in the last 7 days goes to an AI, which picks what is worth writing about.
MCP is for when an agent is already reasoning about the material. If Claude Code just finished a feature with you, it knows which part was interesting in a way a commit-log scan never will. It can call get_mining_context, read your local files itself, and push two good ideas instead of eight generic ones.
What it can and cannot do
push_ideas adds ideas with status new. create_post writes a post into the review queue, awaiting_approval by default, and can also schedule it to your connected accounts: a scheduled publication only goes out if a human approves the post before its time, otherwise it expires.
Approving and scheduling need an explicit, separate consent
By default a connection can only add to your review queue. Approving a post and having a scheduled publication actually go out to your accounts needs the elevated access level, which you consent to on its own screen when you connect a client, separately from read and standard write access. Without it, approve_post and create_post's approve argument are both refused, and everything an agent creates waits for you in Studio.
Even with elevated access, every approval is recorded as your act: whichever user granted the connection, in their name, auditable exactly like a Studio click. An agent telling you it "posted" something is still wrong: publishing itself always waits for the scheduled time and the platform's official API, never an MCP call.
The server also never reads your machine. It has no access to your git history, your notes or your files. An agent running locally reads those itself and sends only the finished ideas.
Brands
One credential reaches every brand on the account, whether it is an API token or an OAuth connection. Each call acts on exactly one, resolved most-explicit first:
- The tool's
brandargument, holding abrand_idfromlist_brands. - The
X-Postlyra-Brandheader, if the client sends one. - The account's only brand, if there is exactly one.
An account with several brands and no brand argument gets an error naming list_brands. There is no way to reach a brand you do not belong to.
In a session touching more than one brand, call list_brands once at the start and pass brand explicitly on every call after that.
You never pick a brand while connecting a client. You pick one per call. So you set a client up once, and a brand you create next month is reachable from it with no reconnect.
Authentication
Two ways in, and they reach the same tools.
An API token. A bearer token in the Authorization header. This is what Claude Code, the CLI and your own scripts use. It carries your full account access.
OAuth. Claude.ai and ChatGPT cannot be handed a pasted token, so they register themselves, send you to a Postlyra approval screen, and get a token that expires. This is the path for connectors. You approve an access level while connecting, and you can disconnect the client later from your profile, under API tokens.
The access levels are:
| Scope | What it allows |
|---|---|
ai:read | See your brands, content ideas, drafts, voice guide and content pillars. |
ai:write.standard | Everything above, plus add new ideas and posts. They land in your review queue awaiting YOUR approval. Nothing publishes without it, and you are notified when something is waiting. |
ai:write.full | Everything above, plus approve posts and schedule them to your connected accounts. Approvals made through this connection are recorded in your name, and scheduled posts publish at their scheduled times unless you reject them in Studio first. |
| Setting | Value |
|---|---|
| Access token lifetime | 60 minutes |
| Refresh token lifetime | 30 days, rotated on every use |
| Re-approval required after | 90 days |
| PKCE | S256, required |
| Dynamic client registration | supported (RFC 7591) |
Tokens do not expire silently in a way you have to manage. The client refreshes them on its own. After the re-approval window you get sent back to the approval screen once.
Each tool below says which scope it needs. Approving only ai:read means a client can read your queue but cannot add to it: the write tools are not even listed to it.