Operator MCP Tool Index

This is the findability page. You know the tool’s name — because your client printed it, a colleague mentioned it, or a model just tried to call it — and you want its parameters. Find the name below and follow the link.

A client connected to https://app.leed.ai/mcp sees one hundred and one tools at 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. Twelve further registry tools exist but are never shown to an MCP client at all; they are listed at the bottom of this page so a name you cannot find here has a definite answer rather than looking like a bug.

Every tool, A to Z

By domain

If you are browsing rather than searching, the same one hundred and one are split across seven pages by what they touch. Each page carries a full parameter table per tool, its backing HTTP method and route, what it returns, and whether the Leed Assistant can call it too.

Two groupings are not obvious from their names. Site structure is the largest domain because it owns page types, search indexes, menus, labels, URL paths, journey stages, autolinks and the company’s own settings — everything that decides where a page sits rather than what it says. And publishing, distribution and users owns every tool that can put something on the live site — publishing, scheduling, pending changes and deployments — as well as the three distribution-channel tools and get_plan_calendar, which belong to the publish-time fan-out rather than to campaign planning.

Registered but never exposed

These twelve tools exist in Leed’s registry and are filtered out before tools/list is answered. An MCP client cannot see them and cannot call one by guessing its name — the response is unknown tool: <name>. Nine are deletes, approvals or a permanent create; three are affordances that only mean something inside the CMS chat window.

Why they are absent rather than merely restricted, and what that means for an AI you have asked to “clean up the old drafts”, is explained on What the Operator MCP Can and Cannot Do. The approval card the assistant shows before running one of them is on Leed Assistant.

The two tools with no backing route

describe_schema and list_analytics_metrics are different from the other ninety-nine. They have no HTTP route behind them: the MCP layer answers them in-process from static data, which is why they are read-only, identical for every workspace, and audited with a fixed low risk tier rather than one read off a registry entry.

• describe_schema { target } returns JSON Schema for one of page, page_type, form or menu, or the full Leed Markdown syntax guide when target is leed_markdown. It is how a model learns the shape of a valid update_page_metadata payload without you pasting one.
• list_analytics_metrics takes no arguments and returns the metric names get_analytics accepts, split into number metrics (a single value plus a trend) and list metrics (tabular).

Counting them yourself

Two counts on this page are derived rather than independent, and they are worth stating so a reader who audits them arrives at the same numbers: the seven per-domain counts sum to one hundred and one, and the twelve withheld tools plus the ninety-nine exposed registry tools account for all one hundred and eleven entries in Leed’s shared registry. The two introspection tools are not registry entries and are counted only in the one hundred and one.

If you have not connected a client yet, start at Connecting to the Operator MCP. If a name here resolves but the call comes back as an error, that is almost always your own role rather than the tool — How Leed’s AI Is Guarded explains which layer produced which message, and MCP Troubleshooting covers connections that fail before any tool runs.