Publishing Your Own Actions to Your Customers

Any account can offer its own services to its own customers through the same connections, permissions, and docs the product's apps use. The account that offers them is the publisher. Its customers connect an app or an AI assistant with exactly the permissions they pick, and the publisher's actions show up beside the product's. A publisher never runs its own code in the platform: its actions are declarations, and each call goes to the publisher's own endpoint.

How It Fits Together

• A publisher declares modules (a group of actions, such as Site Tools) and actions (one thing a customer can ask for). Everything it declares is data in the publisher's own account.
• A customer sees a publisher's actions only after the publisher adds it as a customer of that module, which gives it the matching entitlement (see What Your Account Can Use) and sends it a copy of the definitions. The copy is kept in the customer's own account. A customer without the entitlement does not see the actions in any list, and a call by name is refused the same way as a name that does not exist.
• A customer's connection holds individually picked permissions, as for every app (see MountDev Connections). The publisher's permissions are grouped under the publisher's name, with their levels marked.
• A call is sent from the customer's account to the publisher's endpoint. The customer's account and the relationship between the two accounts are put on the call by the server. They are never taken from what the caller sent, and a publisher can never read another of its customers through a customer's connection.

Permission Ids

A published permission id is <publisher>.<module>.<action>, for example acmetools.sites.scan. The publisher part is a name the account owns, set once. It must be 3 to 24 lower case letters and numbers, starting with a letter. It can never be the name of a product app (built or planned), the workspace, or a word the platform keeps, so a published id never equals, shadows, or looks like a product's id. A published tool name must start with the publisher name and an underscore, and cannot equal a product's tool name. One account holds a name at a time.

Where It Is

Settings, Connections, Publish (a tab beside Connected Services). Owners, admins, and anyone whose role allows publishing see the publisher's side. Anyone whose role allows managing providers sees Services From Your Providers when a provider publishes to the account. Everyone else is told why there is no Publish.

Setting up (for the Publisher)

Everything here is for owners and admins, and for anyone whose role allows publishing (the permission Publish modules and actions to your customers, and decide who gets them). Nothing here is for AI agents, API keys, or connections.

• See what you publish. Action core.publish.state lists your modules, their actions, how many customers hold each, and this month's calls.
• Set the name. Action core.publish.setup sets the name your permissions start with, the name your customers see, and optionally a branded address (a host name such as mcp.example.com). The name cannot change once set. The branded address can.
• Connect your endpoint. The address your calls go to, and its key, are a Connected Service called Published Service Endpoint (see Connected Services). The key is sealed in your account and is opened only when a call is sent. It is sent with each call, never kept anywhere else, and never shown or logged.
• Make an offer. A module is tied to one of your entitlement offers, so customers need it to see the module (action core.entitlements.offers.save).
• Add a module. Action core.publish.module.save adds or changes a module. Action core.publish.module.set turns it on or off. A new module starts off.
• Add an action. Action core.publish.action.save adds or changes an action. It must declare its label, its inputs, its level (read, write, spending, or delete), its permission id, and its tool name. One that leaves any out is refused. An input cannot be named like something the server owns (the account, the customer, the relationship, or SQL). A new action starts off, and action core.publish.action.set turns it on or off.
• Versions. A change to an action's label, description, tool, or inputs is a new version, and every earlier version is kept (action core.publish.action.versions). The level of an action never changes, because connections hold it at that level. Add a new action for a higher level.
• Add and end customers. Action core.publish.customer.add adds an account as a customer of a module: it is granted the entitlement and sent the definitions. Action core.publish.customer.end ends the relationship: its copy is switched off and its connections to you are revoked.
• See who holds what. Action core.publish.customers lists each customer, which of your permissions its connections hold, and its usage this month. These are counts only. You never see what a customer sent or received.
• Docs. Action core.publish.docs returns the docs made from what you publish (see below).

Turning Things Off

Turning an action or a module off removes it from every customer's lists and refuses it by name, in both the API and the MCP, as soon as the customers' copies are updated. Your own endpoint also refuses a call for an action that is off, so a copy that was not updated yet cannot get through.

What a Customer Sees

• Connect an App or AI Assistant lists the publisher's permissions grouped under its name, with levels marked. Everything else works the same: the plain summary (the publisher's modules are named in it), the two consent boxes for changing or deleting data and for charges, the monthly spending limit, quote then confirm, expiry, and the rule of no account-wide grant. Select all works for one module (or one product app) per connection.
• Spending. A spending action asks the publisher's endpoint for a quote, and applies only when the connection confirms the quote. Within the monthly limit the connection confirms its own quote. Above it, or when the owner chose to be asked every time, it waits for an owner or admin in the workspace.
• Deleting. A published delete always waits for confirmation in the workspace, because the publisher cannot say beforehand how much it removes.
• Providers. Action core.publish.providers lists the providers that publish to you and their modules. Action core.publish.leave leaves a module: its copy is switched off, the connections that use it lose its permissions (a connection left with none is revoked), and the publisher is told.
• Ending. When the publisher ends the relationship, the same happens in your account.
• A connection never does more than the member who made it could. If the member can no longer give write, delete, or spending permissions, the connection's published permissions at those levels stop working.

Both Doors, Automatically

A publisher's actions appear in both the REST API (/account/api/v1/actions/<permission id>) and the MountDev MCP, for a connection that holds the permission and an account that has the entitlement. The publisher effectively releases its own MCP server without running one. If it set a branded address, a request that arrives at that address lists only that publisher's tools, with the same sign-in, the same permission checks, and the same limits. It is the same server, never a separate deployment. The address only changes what is listed.

Docs Made from Your Definitions

The same generator that writes the product's permission pages writes yours, from what is on right now: a page for each module, a Permission Finder, a machine-readable index (permissions/index.json), and llms.txt, so a customer's AI agent can build the right connection request. They hold no account data. Action core.publish.docs returns them, and the stable paths under your docs address are:

• /docs/<publisher>/llms.txt
• /docs/<publisher>/permissions/index.json
• /docs/<publisher>/permissions/ (the Permission Finder)
• /docs/<publisher>/<module>/permissions/

What Is Kept, and Where

In the publisher's account: its name, its modules, actions, and versions, its customers and the permissions they hold (ids and counts), and monthly usage counts. In the customer's account: the copy of the definitions it was shown, its connections and grants, and the publisher's name and branded address. The accounts talk through each account's own message queue (definitions, the end of a relationship, and counts of what is held). The platform takes a message in with action core.publish.receive, which no person's role can run. Nothing about a customer's records goes to the publisher, and nothing is kept in the hub or in the code.

What Is Not Built Yet Planned

• The publisher's permissions grouped under its name on the Connect an App or AI Assistant screen (Planned). That screen is built with MountDev Connections; the permission list it reads already carries each publisher's name.
• Serving the generated docs at a public address (Planned). The files are made now; the publisher serves them on its own docs address.
• The front door carrying messages and calls between accounts, and routing a branded address to the workspace (Planned). The accounts' sides are built and tested with the front door stood in.