What the Operator MCP Can and Cannot Do

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

Three facts hold everywhere on this page. Reads are broad: the connection can see essentially everything your own role can see in the CMS. Ordinary writes stay off the live site: page edits, menus, labels, forms and settings wait to be published. Anything that changes the live site, or deletes, stops and asks: thirteen tools — publishing, scheduling, promoting, two narrow deletes and a few bulk operations — return a preview first and act only when called again with confirm: true. And twelve registered tools, mostly deletes, are never shown to an MCP client at all, so a model cannot call them even by name.

The seven domains

One hundred and one tools are advertised when a client calls tools/list: ninety-nine 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 one hundred and one alphabetically with the page each one is documented on.

Ordinary writes wait to be published

No ordinary MCP write goes live; only the confirm-gated publishing tools below put anything on your site. What “not live” means differs slightly by resource, and the difference matters when you go looking for the change afterwards.

• Page bodies are edited with update_page_body, either directly — the default over MCP, and not recoverable — or as tracked suggestions attributed to the connected user, which somebody accepts or rejects in the page editor. On a published page the edit lands on its revision; the live page is unchanged until that revision is published. 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, search indexes, autolinks and company settings land in a draft state. They show up in the pending-changes list — the same list list_pending_changes reads — and reach your live site only when they are published, by a person or with publish_pending_changes. 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 twelve 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 two groups. Nine — the deletes, approving a deliverable and creating a permanent short link — are the destructive tier that the Leed Assistant parks for your approval rather than running outright. The other three are not about risk at all: they have no meaning outside the CMS chat window.

The last three are worth separating from the other nine. 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_chart draws a chart into it. MCP clients get the same analytics data through get_analytics, which returns rows.

The other nine 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 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. Thirteen tools are gated this way today:

In route mode the backing API route runs the dry run itself, validating every item against real permissions and data. In local mode the MCP layer refuses to dispatch at all until confirmed, and builds the preview from your arguments.

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_by_id 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_by_id — 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_by_id 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_by_id again with the same arguments plus confirm: true after the user explicitly approves."
}

A local-mode tool such as 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, and the same instruction string. Each tool’s parameters are on its domain page; the publishing tools are on MCP Tools: Publishing, Distribution and Users.

The convention behind all of them 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 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 reserve_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, page types, search indexes, labels, journey stages, URL paths and aliases, shortcodes (read), assets, users’ profile fields, autolinks, company settings, the pending-changes list, and promoting or retrying a deployment. None of that appears on the consent screen. 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_overview 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. No tool manages CI trusts either.
• Your site repository’s contents. Handlebars layouts, partials, CSS and everything else in the repo are outside the tool surface; promote_staging_to_production can merge staging into production, but no tool reads or writes a file.
• 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 from the CMS is 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.