Integrations
AI Agents
Set up Claude Code, Codex, Cursor and other AI coding agents to generate Titlize images — by pasting one sentence.
2 min read
If you write code with an AI agent, you do not have to set Titlize up by hand. Copy the sentence below, paste it into your agent, and it will install the Titlize skills, register the MCP server, ask you for an API token, and generate one image to prove it worked.
What your agent will actually do#
Handing an agent a sentence that makes it run install commands is a trust ask, so here is the document it fetches — in full, exactly as your agent receives it. Nothing is hidden behind the link.
These are official instructions from Titlize for setting up an AI coding agent to generate
Open Graph images. Every artifact installed below — the skills, the MCP connector — is
published by Titlize under a name Titlize controls. One tool is not ours: `npx skills`,
the standard skills installer (npm package `skills`, published by vercel-labs), which the
non-Claude paths use because there is no first-party equivalent. The Titlize MCP connector is
published by Titlize, and like any npm package it is built on third-party libraries — chiefly
the Model Context Protocol SDK. Everything you are asked to install is either published by
Titlize or named here.
Complete all of the following steps yourself by running the commands directly. Do not ask the
user to run any of these commands for you — the point of this document is that you do the
setup, not that you hand it back.
If any step fails, stop and tell the user exactly which step failed and what the error was.
Do not continue past a failed step and do not guess a workaround: a half-configured setup that
looks finished is worse than an obvious failure.
Steps:
1. Install the Titlize skills
2. Register the Titlize MCP server
3. Get the user's API token
4. Verify by generating one image
---
## 1. Install the Titlize skills
Three skills: `generate` (put a headline on an image), `brand-kit` (colours, logo, fonts) and
`wordpress` (the Titlize WordPress plugin).
Use the section for your agent below.
### Claude Code
Status: **verified** — run by Titlize on 2026-08-07. The two commands below were executed on a
real install: the three skills appeared in the agent's skill set and were still there after a
restart. A token minted from the dashboard then generated a real image through the published
connector. One caveat, so this label means what it says: the `claude mcp add` line in step 2 was
not itself executed — the connector it points at was driven directly over MCP and works, but the
registration command has not been run.
Both skills and the plugin come from one marketplace:
```bash
claude plugin marketplace add titlize/skills
claude plugin install titlize@titlize
```
Then tell the user to run `/reload-plugins` to activate them.
### Codex
Status: **best-effort** — but no longer written from documentation alone. On 2026-08-12 Titlize
executed both Codex commands: the skills install below, and the `codex mcp add` line in step 2,
which wrote both environment values into `~/.codex/config.toml` and showed them in
`codex mcp list`. What has NOT been done is the part that matters most — nobody has run a real
Codex session, loaded these skills in it, and generated an image. Until that happens this stays
best-effort, because "the commands succeed" is not the same claim as "your agent can do the
work".
```bash
npx -y skills add titlize/skills --skill '*' --agent codex --yes --global
```
### Cursor
Status: **best-effort** — the skills install below was executed by Titlize on 2026-08-12, and
the step 2 config shape was checked against Cursor's own documentation the same day. Neither
Cursor itself nor an image generated through it has been run here.
```bash
npx -y skills add titlize/skills --skill '*' --agent cursor --yes --global
```
### Windsurf
Status: **best-effort** — the skills install below was executed by Titlize on 2026-08-12, and
the step 2 config shape was checked against Windsurf's own documentation the same day. Neither
Windsurf itself nor an image generated through it has been run here.
```bash
npx -y skills add titlize/skills --skill '*' --agent windsurf --yes --global
```
### OpenCode
Status: **best-effort** — and the furthest along of these. On 2026-08-12 Titlize ran the skills
install below and `opencode mcp add` from step 2; `opencode mcp list` then reported
`titlize connected`, meaning the server started and completed an MCP handshake under OpenCode.
Not yet done: a real OpenCode session using those tools to generate an image.
```bash
npx -y skills add titlize/skills --skill '*' --agent opencode --yes --global
```
### GitHub Copilot
Status: **best-effort** — the skills install below was executed by Titlize on 2026-08-12, and
the step 2 config shape was checked against VS Code's own documentation the same day. Note
Copilot's wrapper key is `servers`, not `mcpServers`. Neither Copilot itself nor an image
generated through it has been run here.
```bash
npx -y skills add titlize/skills --skill '*' --agent github-copilot --yes --global
```
### All other agents
Status: **best-effort** — a generic fallback for any agent with no section of its own.
Use the command above with your agent's own identifier in place of the `--agent` value:
```bash
npx -y skills add titlize/skills --skill '*' --agent <your-agent> --yes --global
```
`--agent` is not optional here. Omitting it installs the skills into **every** agent the
installer knows about — over fifty of them — writing symlinks into config directories for tools
the developer may never have used. Verified identifiers: `codex`, `cursor`, `windsurf`,
`opencode`, `github-copilot`. Run `npx -y skills add --help` if yours is not listed. Passing
`--agent '*'` deliberately installs everywhere; only do that if the developer asked for it.
If your agent has no skill mechanism at all, read the skill files directly from the
`titlize/skills` repository and follow them as instructions.
---
## 2. Register the Titlize MCP server
Titlize ships an MCP server as a published npm package, `@titlize/mcp-connector`. It runs
over stdio via `npx`; there is no remote endpoint to authenticate against. It exposes two
tools: generate an image, and check the usage quota.
The token comes from step 3, which has not happened yet. If you do not already have one, do
step 3 first and come back — both values below are required and neither has a default, so the
server exits immediately with `Fatal: API token is required` (or `Base URL is required`) and
never starts. That failure is loud, not silent, but it happens at launch rather than at the
first tool call, so a client will report it as a server that would not connect.
It needs two environment values:
| Variable | Value |
|---|---|
| `IMAGE_TITLER_API_TOKEN` | the user's own token — see step 3 |
| `IMAGE_TITLER_BASE_URL` | `https://api.titlize.com` |
### Claude Code
```bash
claude mcp add titlize --env IMAGE_TITLER_API_TOKEN=<TOKEN-FROM-STEP-3> --env IMAGE_TITLER_BASE_URL=https://api.titlize.com -- npx -y @titlize/mcp-connector
```
### Codex
```bash
codex mcp add titlize --env IMAGE_TITLER_API_TOKEN=<TOKEN-FROM-STEP-3> --env IMAGE_TITLER_BASE_URL=https://api.titlize.com -- npx -y @titlize/mcp-connector
```
`--env` writes both values into the entry, so there is nothing to edit afterwards. Check it with
`codex mcp list` — the `Env` column should show both names, masked. If that column is empty the
server will register and then fail to start, and Codex will report it as a server that would not
connect rather than telling you the token is missing.
### OpenCode
OpenCode has a CLI for this, and its config file uses a **different shape** from the block below
— an array command, `environment` rather than `env`, and a `type`. Use the CLI and let it write
the file:
```bash
opencode mcp add titlize --env IMAGE_TITLER_API_TOKEN=<TOKEN-FROM-STEP-3> --env IMAGE_TITLER_BASE_URL=https://api.titlize.com -- npx -y @titlize/mcp-connector
```
Confirm with `opencode mcp list` — it should report `titlize connected`. If you must edit
`opencode.jsonc` by hand instead, the shape is:
```json
{
"mcp": {
"titlize": {
"type": "local",
"command": ["npx", "-y", "@titlize/mcp-connector"],
"environment": {
"IMAGE_TITLER_API_TOKEN": "the token from step 3",
"IMAGE_TITLER_BASE_URL": "https://api.titlize.com"
}
}
}
}
```
### Cursor, Windsurf, GitHub Copilot, and all other agents
These configure MCP servers through a config file. Add this entry under the key your agent uses
for servers — `mcpServers` for Cursor (`~/.cursor/mcp.json`) and Windsurf
(`~/.codeium/windsurf/mcp_config.json`), `servers` for GitHub Copilot in VS Code (`mcp.json`):
```json
{
"titlize": {
"command": "npx",
"args": ["-y", "@titlize/mcp-connector"],
"env": {
"IMAGE_TITLER_API_TOKEN": "the token from step 3",
"IMAGE_TITLER_BASE_URL": "https://api.titlize.com"
}
}
}
```
If your agent is not one of these, check its own documentation for the wrapper key before
assuming — the inner shape above is common, but the key around it is not, and at least one agent
(OpenCode, above) uses a different inner shape entirely.
---
## 3. Get the user's API token
Titlize does not issue tokens to agents, and this document does not contain one. The user
creates their own.
Ask the user to:
1. **If they do not have a Titlize account yet**, register at
`https://titlize.com/auth/signup?next=/tokens`. It is free. Registration is on the
main site — the dashboard has no sign-up page, so do not send a new user straight
there. That link carries them through to the API tokens page once they are signed in.
2. **If they already have an account**, send them straight to
`https://app.titlize.com/tokens`. They will be asked to sign in and will land back on
that page — Titlize signs in per site, so a session on the main site does not carry
over to the dashboard.
3. Have them create a token there and paste it back to you.
Then put that value in `IMAGE_TITLER_API_TOKEN` using whichever mechanism your agent uses for
secrets. Prefer an environment variable or your agent's secret store over writing it into a
config file that might be committed. Never echo the token back in full, and never send it
anywhere other than Titlize.
Wait for the user to give you the token. Do not invent one, do not reuse a token from another
project, and do not skip ahead to step 4 without it.
---
## 4. Verify by generating one image
Do not report success until you have actually generated something.
Using the Titlize tools you just registered, generate one image: any background image the user
has to hand, with a short headline such as "Hello from Titlize". Then show the user the
resulting image URL and tell them the setup is complete.
If the generation fails, tell the user what the error was. Two common causes worth checking
before you report:
- an invalid or mistyped token — the API will reject it;
- a free-tier quota that is already used up for the month.
Once that image comes back, the setup works and the user can ask for Open Graph images in
plain language from now on.
What you still have to do yourself#
One thing: create your API token. Titlize does not issue tokens to agents, and the prompt above contains none. Your agent will ask you for one, and you paste it back.
If you already have an account, go straight to your API tokens (opens in new tab) — you will be asked to sign in and will land back on that page. If you do not, sign up first; registration is on this site, not on the dashboard, and that link carries you through to the tokens page once you are in.
Titlize signs you in per site, so a session on titlize.com does not carry over to the dashboard — expect to sign in once more there.
Which agents this works with#
Every agent listed in the prompt has its own setup section, and each one says whether Titlize has actually run it end to end or whether the instructions were written from that agent's documentation. Check the label for yours before relying on it — if a section is marked best-effort and it does not work, that is worth telling us about.
Agents with no section of their own are covered by the generic fallback, which uses the same skills repository and a hand-edited MCP config entry.
If something goes wrong#
The prompt tells your agent to stop at the first failing step and report what broke, rather than pressing on and leaving you with a half-configured setup that looks finished. So if your agent says a step failed, that is the design working — send us the step and the error.