Connect your AI agent

Agents connect to one MCP endpoint instead of to your CMS. They never receive your CMS credentials, so every change goes through your rules.

Your endpoint is your Lyntcast address followed by /api/mcp:

https://<your-lyntcast>/api/mcp

It uses the MCP Streamable HTTP transport. The exact URL, with copy buttons, is on the AI agents page of your workspace.

Apps that support OAuth (no key needed)

Claude.ai, Claude Desktop and ChatGPT discover Lyntcast’s sign-in automatically.

Claude: Settings → Connectors → Add custom connector, paste the endpoint.
ChatGPT: Settings → Apps & Connectors → Create (developer mode), paste the endpoint.

The app registers itself and sends you to a Lyntcast consent screen, where you sign in, pick a workspace and choose the agent’s trust level. That creates an agent marked “Connected app”. Revoking it on the AI agents page cuts off its tokens immediately.

These apps need a public HTTPS address, so use your deployed Lyntcast (or a tunnel), not localhost.

How the OAuth flow works

Lyntcast implements the MCP authorization spec:

Protected-resource metadata (RFC 9728) at /.well-known/oauth-protected-resource/api/mcp, advertised in the WWW-Authenticate header of a 401 from the endpoint.
Authorization-server metadata (RFC 8414) at /.well-known/oauth-authorization-server.
Dynamic client registration (RFC 7591) at /oauth/register, and client ID metadata documents.
Authorization code flow at /oauth/authorize with PKCE, S256 only, and resource indicators (RFC 8707).
Tokens at /oauth/token: 1-hour access tokens and rotating 30-day refresh tokens with replay detection. Revocation (RFC 7009) at /oauth/revoke.

Agents that use a key

On the AI agents page, create an agent and copy its key (it starts with gh_live_ and is shown once). Send it as a Bearer token.

Claude Code

claude mcp add --transport http lyntcast https://<your-lyntcast>/api/mcp --header "Authorization: Bearer gh_live_…"

Cursor, Windsurf, VS Code and other MCP clients

Add to the client’s MCP config file (for Cursor, .cursor/mcp.json):

{
  "mcpServers": {
    "lyntcast": {
      "url": "https://<your-lyntcast>/api/mcp",
      "headers": { "Authorization": "Bearer gh_live_…" }
    }
  }
}

Your own agent

Any MCP client library works: the Claude Agent SDK, the OpenAI Agents SDK, LangChain, n8n or the Vercel AI SDK. Point it at the endpoint with the header Authorization: Bearer gh_live_….

Tools agents get

Tool	What it does
`list_sites`	Sites the agent may use, the workspace timezone and the agent’s scope (sites, content types, daily limits).
`list_content_types`	Content types on a site (post, page, product…), limited to the types the agent may use.
`search_content`	List or search documents. Returns IDs, titles, fields and a version.
`get_content`	Read one document with all of its fields and its version.
`get_rules`	The workspace rules in plain language, field notes, the timezone and the agent’s own limits and scope. Agents should call it before their first edit.
`check_change`	Dry run: what would happen to a change (applied, held, blocked, and why) without saving anything.
`propose_change`	Create, update or delete. Returns applied, pending (with a review link), scheduled or blocked (with findings). Optional publish_at and revert_at; optional base_version; optional idempotency_key for safe retries.
`get_change_status`	Whether a change was applied, approved, rejected or undone, with the reviewer’s note.

Tips for agents

Pass the version from get_content as base_version. If the document changed since, the change is refused and the agent is told to re-read.
For updates, send only the fields that change. Set a field to null to remove it.
Times for publish_at and revert_at are ISO 8601 and must include a timezone, e.g. 2026-11-09T09:00:00+04:00.
A pending change must not be retried; the agent can poll get_change_status.
Pass an idempotency_key with every propose_change and reuse it when retrying. See Safe retries.

Safe retries (idempotency)

Networks drop responses, and agents retry. A retry must never publish a change twice, so propose_change takes an optional idempotency_key: any string up to 200 characters that the agent picks for one intended change (a UUID works well).

Sending the same key again returns the original change: the same change_id, status and fields, plus duplicate: true. Nothing is applied, queued or notified a second time, even when the two requests arrive at the same moment.
Reusing a key for a different change (other fields, document, site or schedule) is refused with an error that names the original change. Use a new key for a new change.
Keys belong to one agent; two agents can use the same key without clashing.
Without a key, Lyntcast still catches accidental replays: the same proposal from the same agent within 10 minutes, while the earlier one is still pending or live and is the latest change to that document, returns the earlier change with duplicate: true. Changing a value back on purpose (A, then B, then A again) is not treated as a replay.

Scope: what an agent may touch

On the AI agents page, open an agent’s Scope & alerts to limit it to some sites, to some content types (for example only post and page, never products), and to its own daily limits. The agents list shows each agent’s scope in one line.

Changes outside the scope are refused with a plain message, for creates, edits and deletes alike. For edits and deletes the document’s own type decides, never the type the agent claims.
Search and list tools only return content the agent may use. get_content refuses documents of other types.
The agent is told its scope up front, in the MCP server instructions and in list_sites and get_rules, so it doesn’t have to discover it by trial and error.
Content type IDs apply on every site the agent may use: allowing post allows posts on each of them.

Limits

300 MCP requests per minute per agent.
Daily change and delete limits per agent, set by an admin.
Paused agents (individually or by the emergency stop) can read but their changes are refused.

Automatic pause

Lyntcast pauses an agent by itself, and alerts the workspace, when its behaviour looks wrong:

a burst of more than 60 changes in 10 minutes;
10 or more changes blocked by rules in an hour (often a sign of prompt injection);
half or more of its recently reviewed changes rejected;
a loop: 8 or more changes to the same document in 30 minutes, or the same field switched back and forth (A → B → A → B). The reason reads like “paused automatically: it changed ‘Pricing page’ 9 times in 30 minutes, which looks like a loop”.

A paused agent can still read. An admin resumes it on the AI agents page. Automatic pausing can be turned off in workspace settings.

“Agent went quiet” alerts

Agents that run on a schedule can fail silently. In an agent’s Scope & alerts, turn on Alert me if this agent is silent for more than [n] hours. When the agent hasn’t proposed a change for that long, owners and admins get a Slack message (if Slack is set up) and an email, with the time of its last change in the workspace’s timezone. The alert is sent once per silence and re-arms as soon as the agent proposes a change again. Paused and revoked agents don’t alert. It is off by default.