The Moonbrush MCP server
As of October 20, 2026.
The Moonbrush MCP server lets a person work in Moonbrush from a conversation with an AI assistant. It is a standard remote Model Context Protocol server at one address, https://mcp.moonbrush.ai/mcp. Claude is the assistant it is built and tested with, on claude.ai, Claude Desktop and Claude Code. The server calls only Moonbrush’s own platform, signed in as that person, and holds no other login.
Using the MCP with ClaudeConnect, check where you are, and what to ask, job by job.
Access and rolesSign-in, sessions and roles in the app, which the MCP server follows.
What it is
Section titled “What it is”- A standard remote MCP server. It speaks the protocol’s Streamable HTTP transport and its authorization flow: OAuth 2.1 with PKCE, behind Moonbrush’s own sign-in page.
- The same tools on every Claude surface. claude.ai, Claude Desktop and Claude Code reach the same server, with the same tools, checks and refusals.
- A way into the app, not a second copy of it. Every answer comes from the platform, and every change is the platform’s own action, made the way the app makes it.
Signing in
Section titled “Signing in”- The person’s own login. A person signs in on Moonbrush’s own sign-in page with the email and password they use in the app. The password goes to the platform’s login once, server to server, and is never stored, cached or logged. When the login has two-factor authentication on, the page asks for the code from the person’s authenticator app.
- The same workspaces as the app. A session reaches exactly the workspaces the platform lets that login open, and opens each one only through the platform’s own switch. It works in one workspace at a time, and every answer names it.
- The same roles as the app. An organization admin or a member can make changes where the app’s role allows them, each behind the person’s yes (below). A view-only member has no tools that change anything. A Moonbrush platform administrator’s login reads and never writes. The platform still decides every request: the server’s own checks sit on top of the app’s.
- Sessions end with the app’s. A Claude session is short-lived and renews only by renewing the person’s platform session. A sign-out everywhere, a password change or a suspension in the app ends the Claude session too, and the server never signs in again on its own.
The first thing a session says is who is signed in and where:
You’re signed in as [your name] ([your email]). Your agency is Moonbrush. You’re working in [the workspace].
Clients you can work in: [each client, by name].
Before any change, I’ll ask your yes and name the client.
What it can do
Section titled “What it can do”| Job | What a person can ask for |
|---|---|
| Onboard a client | A new client from its name and website, as the app’s New client makes one; where onboarding stands; a paid read of the client’s website into the client’s record, under the platform’s cost cap; the kickoff questions; the Outcome; and the site tag set up for the client’s web team |
| Build audiences | A plan of audience groups counted before anything is built, a count from Moonbrush’s own search, a saved audience, a do-not-contact list kept out, and an audience’s makeup as the app’s Analysis page shows it |
| Run a campaign | A draft campaign for one Outcome, the ad for each audience, going live behind Moonbrush’s go-live check, a pause, resume or end, a new budget or new dates, an audience swap, and the campaign’s package built in Moonbrush |
| Report | The client weekly built from the numbers Moonbrush already stores, the campaign table, the campaign’s readout, and an Outcome’s “did it from our ads” |
| Clean up | One item at a time archived, deleted or restored, as the platform allows |
What it never does
Section titled “What it never does”- Send anything to an ad platform. The server calls only Moonbrush’s own platform and holds no ad platform login. Taking a campaign live, pausing it or changing its budget or dates changes Moonbrush’s record of the plan. The person takes the matching step in the ad platform’s own console, and Claude records that step only as the person’s word.
- Name a person on a list. A search sample shows the kind of people who match, such as an age band, a state or a job title, with no name, contact detail or Moonbrush ID. An audience’s makeup comes back as counts and shares, and a do-not-contact list as a count. Neither names anyone.
- Change anything without the person’s yes. Every save, upload or switch of workspace, like every other change, asks the person’s yes first, with the workspace named, the same way in every client. The request must carry the workspace’s exact name, or nothing is sent. Where the person’s Claude app can show a confirmation, Moonbrush asks the person directly, and Claude can neither see nor answer it.
- Export people. No tool exports or downloads an audience, downloads a campaign package or pushes people to a destination. The package is built in Moonbrush, and the person downloads it in the app.
- Install or send. It places no tag on a website: the client’s web team does. The weekly, the note to the client and any link are the person’s to send.
Some actions stay in the app alone: renaming an audience or an Outcome, connecting Google Drive, a new tag key or stopping the tag, and any campaign setting beyond the ones above.
What leaves the platform through it
Section titled “What leaves the platform through it”Nothing the platform does not already serve that login in the app. The server reaches Moonbrush only through the platform, signed in as the person, and sends data nowhere else.
- Answers. What a tool answers goes into the person’s conversation with Claude. Answers pass field allow-lists: no contact detail, no Moonbrush ID and no row per person. Text a person typed into Moonbrush, such as a note on a client’s record, comes back as it was typed.
- No file of people. No audience file, export or package leaves through the server.
- Files coming in. A file the person brings (a list, a brief, a report) goes into the platform by a one-time link the person opens in their own browser, signed in to the app, never through the conversation.
- Links shown once. An upload link, and a share link the person makes, each appear once, in the answer that made it, and are withheld from every later answer and every log.
See What leaves the platform for the app’s own paths.
What the server keeps
Section titled “What the server keeps”- A trail, for the person who made it. One line per tool call: the tool, the workspace, the platform requests it made and the result. Never a password or a code, and search criteria only as a hash. Each login reads back its own lines only, and lines are deleted after a fixed retention period.
- Short-lived counts. A count is kept for a short time, so a save matches the count the person saw. Build records carry no person.
- Sealed sessions. The platform session behind each Claude session is kept encrypted in the server’s own database, which has no public address.
- No secret in any log. The password, the code and every session credential are withheld from every log record.
Claims
Section titled “Claims”The claims this page and Using the MCP with Claude make, in the columns of the claims register. Each is a description of the product, not a scientific claim, so none is graded. Each was checked against the MCP server, version 1.38.3, on October 20, 2026. Under NDA means the server’s code and tests are shown to qualified reviewers in a technical session.
Table 1. Claims about the Moonbrush MCP server.
| Claim | Where it is made | Research basis | Grade | Moonbrush evidence |
|---|---|---|---|---|
| A standard remote MCP server at one address, over Streamable HTTP, signed in through OAuth 2.1 with PKCE | What it is | MCP specification (transport and authorization) | Not graded | Published: this page. Under NDA: the code and tests |
| Built and tested with Claude, on claude.ai, Claude Desktop and Claude Code | Introduction, Connect | Product rule | Not graded | Under NDA: the code and tests |
| It calls only Moonbrush’s own platform, signed in as the person, and holds no other login | Introduction, What leaves | Product rule | Not graded | Under NDA: the code and tests |
| The password goes to the platform’s login once, server to server, and is never stored, cached or logged | Signing in | Product rule | Not graded | Under NDA: a test that plants a password and finds it in no log, table, file or answer |
| With two-factor authentication on, the page asks for the authenticator app’s code | Signing in | Product rule | Not graded | Under NDA: the code and tests |
| A session reaches exactly the workspaces the platform lets the login open, only through the platform’s own switch, one at a time, and every answer names it | Signing in | Product rule | Not graded | Under NDA: the code and tests |
| An admin or member changes only where the app’s role allows; a view-only member has no tools that change anything; a platform administrator’s login reads and never writes | Signing in | Product rule | Not graded | Under NDA: the code and tests |
| The platform decides every request; the server’s checks sit on top of the app’s | Signing in | Product rule | Not graded | Under NDA: the code and tests |
| A Claude session renews only with the platform session, and ends when the app’s session ends | Signing in | Product rule | Not graded | Under NDA: the code and tests |
| The session’s first words say who is signed in, the agency, the workspace, the clients and the guard before any change | Signing in, Check where you are | Product rule | Not graded | Published: the words, on this page |
| The jobs listed under What it can do are the server’s tools today | What it can do, Using the MCP with Claude | Product rule | Not graded | Under NDA: the tool list and tests |
| A new client takes its name and website, as the app’s New client does, and the site read starts once it is added | What it can do, Onboard a client | Product rule | Not graded | Under NDA: the code and tests |
| It holds no ad platform login and sends nothing to an ad platform; a campaign’s lifecycle changes Moonbrush’s record, and the person takes the step in the ad platform | What it never does | Product rule | Not graded | Published: Go live, Pause and Resume never act on the ad platform (changelog). Under NDA: the code and tests |
| A search sample shows the kind of people who match, with no name, contact detail or Moonbrush ID; makeup is counts and shares; a do-not-contact list is a count | What it never does | Product rule | Not graded | Under NDA: the sample allow-list and its tests |
| Every change asks the person’s yes with the workspace named, the request must carry its exact name, and where the app can show a confirmation Claude can neither see nor answer it | What it never does, FAQ | Product rule | Not graded | Under NDA: the code and tests |
| No tool exports or downloads an audience, downloads a package or pushes people to a destination | What it never does, What leaves | Product rule | Not graded | Under NDA: the tool list and tests |
| Answers pass field allow-lists: no contact detail, no Moonbrush ID, no row per person; typed text comes back as typed | What leaves | Product rule | Not graded | Under NDA: the allow-lists and tests |
| A file comes in by a one-time link opened in the person’s own browser, never through the conversation | What leaves | Product rule | Not graded | Under NDA: the code and tests |
| An upload link and a share link appear once and are withheld from every later answer and log | What leaves | Product rule | Not graded | Under NDA: a test that finds a link in no log record, table or later answer |
| One trail line per tool call, with no password or code and criteria only as a hash, read back by its own login only and deleted after a fixed period | What the server keeps | Product rule | Not graded | Under NDA: the retention period, the code and tests |
| Platform sessions are kept encrypted in a database with no public address; no secret is written to any log | What the server keeps | Product rule | Not graded | Under NDA: the code and tests |