What the Operator MCP Can and Cannot Do

A client connected to the Operator MCP can do considerably more than the consent screen implies, and considerably less than “full access to your workspace”. This page draws the actual line, because the two summaries a reader normally meets — the four bullets on the consent screen and the vague reassurance that “AI can’t publish” — are each true and each incomplete.

Three facts hold everywhere on this page. Reads are broad: the connection can see essentially everything your own role can see in the CMS. Writes are drafts and suggestions: nothing an MCP client writes is live. Publishing and deleting are absent, not restricted — sixteen registered tools are never shown to an MCP client at all, so a model cannot call them even by name.

The seven domains

Sixty-eight tools are advertised when a client calls tools/list: sixty-six from Leed’s shared tool registry, plus two introspection tools that run inside the MCP layer and have no backing API route. They are documented across seven pages, grouped by what they touch.

If you know the tool’s name and want to jump straight to its parameters, the Operator MCP Tool Index lists all sixty-eight alphabetically with the page each one is documented on.

Writes are drafts and suggestions

No MCP write goes live. What “draft” means differs slightly by resource, and the difference matters when you go looking for the change afterwards.

• Page bodies land as tracked suggestions attributed to the connected user — insertions and deletions marked up exactly like a colleague’s suggested edit, which somebody accepts or rejects in the page editor. The one exception is a page whose body is still empty, which can be filled outright. Authoring Pages Over MCP is the workflow, and Suggesting Mode and Tracked Changes is what your team sees.
• Page metadata, menus, labels, forms, page types and autolinks land in a draft state. They show up in the pending-changes list — the same list list_pending_settings_changes reads — and reach your live site only when a person publishes. Publishing Changes covers that step.
• Contacts, accounts, campaigns and personas are not site content and have no draft state. A write there is a real write to your CRM data — reversible by editing it back, but not held behind a publish.

The sixteen tools it is never shown

These are not restricted-but-available. They are filtered out of tools/list before the response leaves the server, so a client never sees them and a model cannot invoke one by guessing its name. The error a client gets for trying is unknown tool: <name>.

They fall into five classes. Four of them — delete, publish, create a short link, approve a deliverable — are the destructive tier that the Leed Assistant parks for your approval rather than running outright. The fifth is not about risk at all: three tools that have no meaning outside the CMS chat window.

The last three are worth separating from the other thirteen. They are excluded because they are meaningless over MCP, not because they are dangerous: get_current_resource reads the screen you are looking at in the CMS, and an MCP client has no such screen; suggest_next_steps renders buttons into the chat transcript; get_analytics draws a chart into it. MCP clients get the same analytics data through query_analytics, which returns rows.

The other thirteen are the destructive tier, and the Leed Assistant can run them — it stops and shows you an approval card first. Leed Assistant explains what parking looks like and how long an approval stays valid.

The two tools that stop and ask

MCP clients have no uniform way for a server to interrupt and ask a question, so Leed expresses approval inside the tool contract instead. Two tools are gated this way today:

The first call — with confirm omitted or false — changes nothing and returns a preview. The model is instructed to show that preview to you and to call the tool a second time with the same arguments plus confirm: true. There is no other way through: no separate confirm endpoint, no token to carry, no session state. The same arguments, twice.

sequenceDiagram
    autonumber
    participant U as You
    participant C as Your MCP client
    participant S as app.leed.ai/mcp
    participant R as /api/page/schedule-bulk
    U->>C: "Schedule these twelve posts for Monday 09:00"
    C->>S: schedule_pages with pageIds and publishedAt
    S->>R: dispatch with confirm: false
    R->>R: Check each page — exists, page:publish, schedulable status, required fields
    R-->>S: dryRun true — wouldSchedule, wouldFail, per-page results, instruction
    S-->>C: Preview envelope — nothing changed
    C->>U: Renders the plan: 10 would schedule, 2 would fail
    U->>C: Approves
    C->>S: schedule_pages — same arguments plus confirm true
    S->>R: dispatch with confirm: true
    R->>R: Schedule each page that validates, per page
    R-->>S: dryRun false — scheduled 10, failed 2, per-page results
    S-->>C: Result
    C->>U: "Ten pages scheduled; two need a summary first"

A real preview from schedule_pages looks like this:

{
  "dryRun": true,
  "publishedAt": "2026-09-08T09:00:00.000Z",
  "total": 3,
  "wouldSchedule": 2,
  "wouldFail": 1,
  "results": [
    { "pageId": "1c6f…", "title": "Autumn release notes", "currentStatus": "DRAFT", "wouldSchedule": true },
    { "pageId": "9ab2…", "title": "Pricing update", "currentStatus": "APPROVED", "wouldSchedule": true },
    {
      "pageId": "44d0…",
      "title": "Field guide",
      "currentStatus": "PUBLISHED",
      "reason": "Page is PUBLISHED and cannot be scheduled — revise it first",
      "wouldSchedule": false
    }
  ],
  "instruction": "This was a preview — nothing was changed. Present this plan to the user and ask for approval; only call schedule_pages again with the same arguments plus confirm: true after the user explicitly approves."
}

set_campaign_audience previews differently, because its dry run never leaves the MCP layer: the envelope is built from your validated arguments and carries preview: true, the tool name in action, a one-line summary, an effects array listing the persona and account ids, and the same instruction string. Its parameters are on MCP Tools: Campaigns and Personas; schedule_pages is on MCP Tools: Publishing, Distribution and Users.

The convention behind both is recorded in Leed’s own source: any new destructive, bulk, or publish-adjacent tool exposed over MCP must be registered through the confirmation wrapper, or carry a written reason why it is exempt. Expect the list of two to grow rather than the rule to bend.

Your role is still the floor

That is worth stating plainly because the failure mode is confusing: a model that can see create_page will happily try it, and the error it gets back is a tool error rather than a broken connection. Roles and Permissions explains the six roles, and the Privilege Matrix is the per-privilege grid. The layered picture — identity, tool visibility, risk tier, confirmation, audit — is on How Leed’s AI Is Guarded.

There is also a self-describing shortcut: describe_capabilities returns your own system-wide privileges plus any resource-level overrides, so you can ask your client “what am I allowed to do here?” and get an answer from the same data the enforcement uses.

Why the consent screen understates this

The live surface also covers contacts, accounts, personas, campaigns, campaign deliverables, distribution channels, labels, journey stages, URL paths, shortcodes (read), page types, users’ profile fields, autolinks and the pending-changes list. None of that appears on the consent screen. Nothing there is wrong — it is a summary that is shorter than the thing it summarizes, and this page is the version to trust.

If you have not connected a client yet, Connecting to the Operator MCP walks the sign-in and shows the screen in question.

Things it cannot reach at all

Some limits are structural rather than a matter of which tools are hidden. Over the Operator MCP there is no path to:

• Billing, payment or subscription state. No tool reads or writes an invoice, a card, a plan change or a quota. get_company reports your entitlement tier as one field in a workspace summary, and that is the entire billing surface.
• Creating, deleting or inviting users, and changing anyone’s role or email. update_user writes profile details — name, job title, bio, contact fields — and nothing else.
• Your site repository or its templates. Handlebars layouts, partials, CSS and everything else in the repo are outside the tool surface entirely.
• Another workspace. A connection is bound to exactly one workspace at consent time. To work in a second, connect again and pick it.
• Your natural-language prompt. This is a limit in your favor: Leed records the tool calls your client decided to make, never the words you typed.

Two of those deserve a pointer rather than a shrug. Publishing is always a person’s decision in the CMS, described in Publishing Changes; and the absence of an in-CMS audit-log screen, along with everything else this product deliberately does not ship, is cataloged in Settings You Will Not Find and Known Limitations.