MCP Tools: Pages and Content

Eleven of the sixty-eight Operator MCP tools work on pages. Two create them, three read them, two write bodies, one changes metadata and three search published content. This page is the parameter reference: what each tool takes, what it gives back, and where the sharp edges are.

It is deliberately not the workflow. The order these tools must be called in, why a body can be filled only once, and what happens when an anchor goes stale are all on Authoring Pages Over MCP — read that first if you are writing content rather than looking up a field. Every tool name here is also in the alphabetical Operator MCP Tool Index.

All eleven are available to the Leed Assistant as well as to MCP clients, and all eleven dispatch to the same permission-checked API routes the CMS itself calls — so your role is the ceiling on every one of them.

Creating pages

create_page

POST /api/page · Returns { page: { pageId, title } }, also delivered as structuredContent · Available in the assistant

Creates the page in DRAFT status with an empty body and hands back its pageId. That id is minted server-side and cannot be supplied, which is what makes a multi-page import a two-pass job.

{ "pageTypeId": "u05nxr", "title": "Installing the CLI" }

{ "page": { "pageId": "a1b2c3d4-5e6f-4a7b-8c9d-0e1f2a3b4c5d", "title": "Installing the CLI" } }

A documentation or API page is appended to that page type’s bound left-nav menu at top level, with a flat path. It cannot be created inside a folder over MCP — folder placement is a menu save, described in Folders Set Your URLs.

create_page_draft

POST /api/page/from-markdown · Returns the created page · Available in the assistant

The one-shot: creates the page and sets its body in a single call. Right for a standalone page, wrong for a set that cross-links, because the body it writes cannot reference a page that has not been reserved yet — and like fill_page_markdown, it is a fill, so you get one attempt at the body.

The markdown you send is Leed Markdown; Overview and Cheat Sheet has one example of every feature, and raw HTML other than <br> fails the whole call.

Reading pages

get_page

GET /api/page/:pageId · Returns the page record · Available in the assistant

Metadata, status, labels, dates and SEO fields. The body is not included — that is get_page_markdown.

get_page_markdown

GET /api/page/:pageId/markdown · Returns { markdown }, also delivered as structuredContent · Available in the assistant

Returns the body as Leed Markdown with every top-level block carrying its {data-id="…"} anchor. Those ids are the only addressable targets for apply_page_markdown_ops, and they must come from a read you just made — never from memory and never invented.

{
  "markdown": "## Requirements {data-id=\"8c07b3\"}\n\nNode 20 or later. {data-id=\"1de590\"}\n"
}

The markdown reflects the clean accepted-state body: a deletion that is still pending as somebody’s tracked suggestion is not shown.

list_pages

GET /api/page · Returns the pages visible to you · Available in the assistant

Both filters are optional and independent. The list is already scoped by your role, so a Read Only connection sees a shorter list than an Administrator’s — that is the permission model, not a bug. Managing Pages covers the same list as the CMS presents it.

Writing bodies

fill_page_markdown

POST /api/page/:pageId/content/fill · Returns { page: { pageId } }, also delivered as structuredContent · Available in the assistant

New blocks need no data-id — ids are assigned on import. On a posts page type, markdown using a formatting feature the type disables is rejected with a 400 naming the offending features.

apply_page_markdown_ops

POST /api/page/:pageId/content/ops · Returns { page: { pageId } }, also delivered as structuredContent · Available in the assistant

Each op is one of four shapes. insertAfter, insertBefore and replace take anchorId and non-empty markdown; delete takes anchorId alone.

{
  "pageId": "a1b2c3d4-5e6f-4a7b-8c9d-0e1f2a3b4c5d",
  "ops": [
    { "type": "replace", "anchorId": "1de590", "markdown": "Node 22 or later." },
    { "type": "insertAfter", "anchorId": "8c07b3", "markdown": "Bun 1.3 is also supported." }
  ]
}

Changes land as tracked suggestions attributed to the connected user, never as a direct write. If any anchor is missing, targeted twice, or already carries a pending suggestion, the entire op-set is rejected with a 409 and nothing is applied. The exact messages and the recovery for each are on Authoring Pages Over MCP; what your team then sees is on Suggesting Mode and Tracked Changes.

Changing metadata

update_page_draft

PUT /api/page/:pageId · Returns the updated page · Available in the assistant

pageId is the only required field; every other field is optional and only the ones you send are written. These are the same fields the editor’s right rail exposes, described for humans on Page Settings.

Three of them behave in ways worth knowing before you send a bulk update:

• slug — changing it recomputes the page’s URL and stages a next path row for the next publish. The value is de-duplicated on the way in, so the slug you get back may carry a -2 suffix. Changing title alone does not re-slug an existing page; only create_page derives a slug from a title.
• pageTypeId — moving a page to another page type also recomputes its path, and moving it to a non-documentation type clears its folder ancestry.
• path — present in the tool’s schema and silently dropped by the route. The docs menu is the only writer of a docs page’s folder ancestry; a path persisted here would desync the published file location from the recorded URL. A call that sets it appears to succeed and does nothing.

Two notes on that table. previewOnly is documented because it is in the schema, not because it is a recommended workflow — there is no CMS control for it, and a page carrying it is absent from your production site and from the search index that search_docs queries. This documentation set sets it on zero pages.

And modifiedAt is not settable. It is stamped server-side on every metadata write, so an import cannot backdate it. publishedAt is settable and is load-bearing for sort order, sitemaps, feeds and structured data — an AI creating pages should set it deliberately rather than leave it for somebody to notice later.

Searching your own content

search_docs, search_pages and search_api are one search engine behind three hard-scoped views. The page-type kind is baked into each tool’s route rather than passed as an argument, so a model cannot cross from documentation into blog posts by changing a parameter.

All three take the same arguments.

GET /api/page/content-search · Returns ranked pages with snippets · Available in the assistant

pageTypeIds is the versioning axis: it is intersected server-side with the page types the tool’s kind already resolves to, so passing a blog page type to search_api narrows the search to nothing rather than escaping into blog content.

Only published pages are searchable. A draft an AI just created will not appear until somebody publishes it, which surprises people mid-import; use list_pages to see drafts.

This is the same engine that powers search on your published site, described from the reader’s side on Live Documentation Search.

Which fields a page type requires before any of these pages can be published is set per type; Configuring a Page Type covers that, and the full boundary of what a connected client may do is on What the Operator MCP Can and Cannot Do.