The MCP server

What it is

A remote MCP server at https://api.kwern.app/mcp. It reads and writes Kwern's data: your products, their foundation doc, growth plan and memory, their connector snapshots, their approval feed, their recommendations and their journal, plus the open skills library. It also calls your connectors' own APIs for your agent, signed by Kwern, so your credentials stay in Kwern.

It never runs a skill, never starts an agent, and never spends a token on Kwern's side. The model on the other end is yours.

Add it to a client

In Claude Code:

claude mcp add --transport http kwern https://api.kwern.app/mcp

Any MCP client that speaks streamable HTTP and OAuth works the same way: point it at the same URL. The first call opens Kwern's consent screen in your browser, where you pick the account and whether the client may write. A read token gets the resources and the read tools, which read your connectors through Kwern; a write token also gets approve, mark as done, reject and the foundation doc, puts your own posts on the calendar, where they go out at their hour without another click in Kwern, and writes to your connectors.

Everything is bound to the account the token was issued for. Another account's products are not reachable, not even by id.

What it exposes

The library resources:

• kwern://products — every product this account owns, with the id every tool takes
• kwern://skills — the marketing skills Kwern hosts, read-only

The resources of a product, at kwern://products/{id}/{name}: foundation, growth-plan, memory, launch, snapshots, outputs, feed, recommendations, journal.

The read tools:

• list_products — the products this account owns
• state — where one product stands in a single call: its surfaces, its connectors and their health, its agents and what paused them, what waits in the approval feed, how current its docs are, which repository backs it
• list_proposals — the approval feed, filtered by category, channel or state
• get_proposal — one proposal and the state it is in
• read_connector_api — calls an endpoint that reads on the API of one of the product's connectors, signed by Kwern

The write tools, on a write token only: approve_proposal, mark_proposal_done, record_reply, reject_proposal, write_foundation_doc, edit_loop, upload_media, create_post, edit_post, move_post, write_connector_api.

Publishing the Writer agent's articles

Kwern never publishes to a blog itself, so an article ends where you put it:

1. list_proposals with category: ["article"] and state: "pending" — the articles waiting for you
2. get_proposal — the Markdown body as content, and frontMatter with the title, slug, target keyword, meta description, article type and the prompt for an open-graph image
3. publish it on your side
4. mark_proposal_done — this is what ends an article

approve_proposal never ends one: Kwern cannot publish to a blog, so there is nothing to approve.

Kwern's own blog is published exactly this way, by a scheduled client with a token like yours: it writes each article into the repository that serves kwern.app, opens a pull request, and calls mark_proposal_done once the pull request merged.

Approving from a client

On a channel Kwern can write to — a post or a Thread on X, LinkedIn, Apple Ads, Google Ads, an App Store review reply, a pull request — approve_proposal publishes. A post is the exception: it arrives planned for a day and an hour, approve_proposal agrees to that hour and Kwern publishes it then, unless you pass publishNow: true to send it at once. It hands back the proposal in the state it reached and its id, so you read it back with get_proposal to see whether the publish landed.

Posting from a client

create_post puts your own post on the calendar of a product, on X or LinkedIn. It takes the product, the channel, a title, the posts in order (two or more make a thread on X) and an optional hour, written 2026-10-08T09:00:00Z.

The post is born approved: the call is your click, so it never waits in the approval feed. With an hour ahead it is scheduled and Kwern publishes it then; with no hour, or one already behind, it goes out on the call. The answer is the post in the state it reached, the channel's reason in error when the channel refused it, and its id to read it back with get_proposal. The same call made twice puts one post on the calendar.

Any post that has not gone out, yours or an agent's, can change afterwards. edit_post takes the proposal id and the whole new list of posts; a scheduled post keeps its hour. move_post takes the proposal id and a new hour; on a post an agent left pending, it is the approval for that hour. reject_proposal cancels a scheduled post, and approve_proposal on one sends it now.

With pictures or a video

A post carries up to four pictures, or one video, on X and LinkedIn. The bytes go from your disk straight to Kwern's storage, never through the client's context:

1. upload_media with the file's name, contentType and byteSize — the answer holds the file's id, an uploadUrl, and when it expires an hour later
2. PUT the file to uploadUrl, with Content-Type set to the answered contentType and exactly byteSize bytes: curl -X PUT -H "Content-Type: image/png" --data-binary @launch.png "$uploadUrl"
3. create_post, or edit_post, with the id and an alt in the post's media: { "text": "Gymup 2.0 is out.", "media": [{ "id": "…", "alt": "The set log, one tap from the home screen." }] }
4. get_proposal with the answered id, to see whether the publish landed

A post naming a file whose bytes have not arrived is refused with that reason: send them, then call again. A file over 500 MB is refused at upload_media, and one no post carries is deleted a day later.

Calling your connectors through Kwern

Your agent reaches the API of every connector the product holds without connecting that service a second time. Kwern keeps the credentials and signs each call with your connection, so no token reaches your agent, its transcripts or its logs.

1. state — lists the product's connectors and their health
2. read_connector_api with productId, service, method, path and, if the endpoint takes them, query and body — Kwern adds the service's base URL and answers with the service's status and body as the service wrote them, its refusals included
3. write_connector_api with the same arguments, on a write token — the change is sent at once, with no approval in Kwern

The tool descriptions list each service with its base URL and its API reference. A change sent to read_connector_api comes back as skipped, naming write_connector_api. A refusal from the service, such as a 403 on a grant that does not cover the change, comes back as the service wrote it. A post created through write_connector_api goes out at once and stays off your calendar; create_post schedules one. Each call is written in the product's journal.

MCP page · Writer agent · All docs