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 sixty-eight tools at 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. Sixteen 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 sixty-eight 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, menus, labels, URL paths, journey stages and autolinks — everything that decides where a page sits rather than what it says. And publishing, distribution and users also owns 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 sixteen 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>. Thirteen are the destructive tier; 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 sixty-six. 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_draft payload without you pasting one.
• list_analytics_metrics takes no arguments and returns the metric names query_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 sixty-eight, and the sixteen withheld tools plus the sixty-six exposed registry tools account for all eighty-two entries in Leed’s shared registry. The two introspection tools are not registry entries and are counted only in the sixty-eight.

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.