Configuring the Docs MCP

Running a Docs MCP asks you two questions: who gets in, and what happens to everyone else. Both are toggles on one settings screen, and this page is the only place they are documented — everywhere else in these docs that mentions them links here.

Read the defaults section before you announce your endpoint. Out of the box, the answer to “who gets in” is anyone who can receive email.

Where the settings live

Go to Settings → System Settings → General and scroll to MCP Configuration. The section carries its own one-line description: “Controls how visitors authenticate to your documentation MCP server.”

The section renders only when the workspace’s mcp entitlement is on. That is a per-workspace switch, not a plan tier — MCP is available on every plan, including Free, and nothing in billing ever turns it off. If the section is missing, see turning the whole surface off below rather than looking at your invoice.

Each switch saves as you flip it, through the same company update the rest of the General screen uses. There is no separate Save step for this section.

Open access to any verified identity

Default: on. With it on, the current-customer check never runs. A visitor proves they own an email address, gives their name, and is granted — and captured, exactly as a customer would be. You trade the gate for a complete record of who is reading your documentation through a machine.

That is the right setting for public or community documentation, and for the common case where the documentation was already going to be public and the sign-in exists to attach a name to the traffic.

Turn it off and the current-customer gate applies to everyone.

The current-customer gate

With open access off, a visitor passes when the registrable domain of their verified email matches one of your accounts flagged as a current customer. Two independent ways to match, either of which grants:

• By contact domain. A contact already recorded under that email domain is linked to an account flagged currentCustomer.
• By account website. A current-customer account’s url resolves to the same registrable domain as the visitor’s email.

The website match is what makes the gate work for a colleague nobody has met: the first person from acme.com passes because the Acme account’s website is https://www.acme.com, not because they were already in your contact list. The comparison is on the registrable domain and is exact — acme.community never matches acme.com, even though a naive prefix match would let it through.

The gate fails closed on an email whose host has no registrable domain — a bare public suffix, for instance. Such an address is denied rather than compared against an empty value.

A denied visitor sees this, verbatim:

This documentation is available to current customers. We could not match your email domain.

It is re-checked on every renewal

The gate is not a one-time admission. A reader’s access token is short-lived and their client renews it quietly in the background, and the same policy runs on every renewal. A customer who churns loses documentation MCP access at their next renewal, with nothing for you to do and nothing to remember. The renewal window and the token lifetimes are in the reader sign-in flow.

Where currentCustomer is set

On the account record, in Engage. Open the account and set it there — accounts covers the record and its firmographic fields, including the url that the second half of the gate reads. The same two fields can be set over the Operator MCP with update_engage_account, documented in MCP tools: contacts and accounts — useful when you are syncing customer status from somewhere else.

An account with the flag set but no website recorded still works; it just relies on the contact-domain half of the gate, which means someone from that domain has to be in your contacts already.

Capture leads from non-customers

Default: on. This toggle only governs what happens on the denial path, so it does nothing at all while open access is on.

• On — capture first. The non-customer verifies their email, fills in the profile step and is written to your contacts with a docs_mcp opt-in, along with a denied event carrying their new contact id. Only then do they see the no-access screen: “No access yet. Thanks for verifying your email. Your company does not currently have access to the … documentation.”
• Off — gate first. The check runs immediately after the email step. A non-customer is refused before a verification code is sent, nothing is written to your contacts, and the denial is recorded with only the attempted email and domain.

Choose on when interest from non-customers is worth something to your sales team — a developer at a prospect pointing an AI client at your documentation is an unusually strong signal, and they have just typed a verified work email. Choose off when you would rather give a fast, clean “customers only” answer and collect nothing.

How the toggles combine

The first two rows are identical on purpose. With open access on there is no denial path left for the capture toggle to govern, so its position has no effect — a real setting that is genuinely inert in that combination, rather than one that does something subtle.

Where the captured data goes

Captures ride your existing forms machinery rather than a separate store. A verified visitor’s email, name and any optional details are written through the same path an on-site form fill takes, anchored to a protected system form named Docs MCP — protected meaning the Forms screens cannot edit or delete it.

The practical result is that captured readers show up in the places you already look: in your submissions alongside every other form fill, and in your contact records with a source of mcp. Each capture records the visitor’s marketing opt-in, and both screens that ask for details state it before they submit: “By submitting your details you are opting in to engage via email with” your company.

Form submissions covers how submissions behave generally, and contacts is where the resulting people live.

Separately from the contact record, every tool call and every denial writes a request-log row — the tool, its inputs including the search text, the result count and the visitor. That log is the demand signal described in the Docs MCP overview.

Turning the whole surface off

The mcp entitlement is a kill switch, and it is the only thing that removes the surface entirely. It is per workspace, defaults on, and nothing in billing ever clears it — there is no plan that lacks it and no upgrade that restores it.

With it off:

• https://YOUR-DOMAIN/mcp and the two OAuth discovery documents are refused at your own site worker with a 403 and the body {"error":"mcp_not_enabled","message":"MCP not enabled, upgrade service"}. The request never reaches Leed.
• The public agent discovery documents — /.well-known/webmcp and /.well-known/agent.json — return 404, so a scanner cannot tell they were ever there.
• Leed’s own worker independently returns 404 on the sign-in, registration and token endpoints, so even a stale edge cannot leave the flow reachable.
• The MCP Configuration section disappears from Settings, because there is nothing left for it to configure.

One asymmetry to know if you ever flip the entitlement: your site worker learns its value at build time, so the edge picks up a change on your next deployment, while Leed’s worker reads it live on every request. In between, the surface is off either way — only the status code differs.

Changing a toggle later

Both toggles are read fresh on every sign-in and every renewal, so a change reaches new connections immediately. It does not reach in-flight ones: a reader who is already connected keeps their current access until their client next renews, then meets the new rule.

That matters most in one direction. Switch open access off on a site that has been open, and non-customer readers do not lose access at the moment you flip the switch — they lose it at their next renewal, within a day. There is nothing to revoke by hand.

Everything else on this settings screen is documented in general site settings.