Brightspot connection
The saved link to a Brightspot CMS. In the connection picker it is Brightspot.
Powers these nodes
- Content trigger
- Content action
- Content Query action
- Content Fetch action
- Content Script action
- Remote AI Agent action
Every one of them names a connection, and the connection decides which CMS the node acts on and whose permissions it acts with.
Fields
| Field | Required | Description |
|---|---|---|
| Instance Name | No | A memorable name for this instance. |
| Base URL | Yes | The base URL of the Brightspot instance. Normalized to scheme, host, and port on save. |
| Default Sites | No | Sites this connection is scoped to. When set, nodes using the connection are limited to these sites, and a node's blank Sites field defaults to them. |
| Basic Auth → Username, Password | No | HTTP Basic credentials for reaching a protected lower environment that sits behind a gateway. Separate from the sign-in below. |
Connecting
Authentication is OAuth 2.0, and all of it is configured for you: the connection discovers the instance's endpoints from the base URL and registers itself, so there are no client credentials to enter. Fill in the base URL, save, click Connect, and sign in to the target CMS to authorize access.
Once connected, the form shows Connected As—the account on that CMS the connection acts as.
What has to be true on the other side
- The Esca Automations server module must be installed on that CMS. Without it, Connect has nothing to talk to. If connecting fails immediately, ask the CMS's administrator whether the module is installed.
- Its version matters. A CMS running an older version connects successfully but cannot run every node, because some nodes need capabilities a later version added. The Automation Plugin row on the connection shows the version that CMS is running and the version to upgrade to. Nodes affected by a gap say so on the canvas, and a run that hits one names the version it needs.
- The account you authorize with needs permission. Everything an automation does on that CMS runs as the user who clicked Connect, with exactly that user's permissions—so a connection can read and publish whatever that account can, and nothing more. On top of that, the account's role must grant automation permission on the CMS. Without it the connection still completes, but every node that touches the CMS fails, Content triggers never register, and agent nodes cannot run.
Brightspot MCP server
An MCP server is not a connection, and this one is worth keeping straight from the connection above. A connection authenticates the nodes on this page to a CMS. An MCP server hands an AI agent a set of tools it can call as it works, and it authenticates against the CMS's own MCP endpoint separately—a Brightspot connection does not authenticate an agent to that CMS's tools.
Both are managed on the Connections page. Under MCP Servers, choose Brightspot and complete its fields:
| Field | Required | Description |
|---|---|---|
| Name | Yes | Identifies the server, and its tools, to the agent. Keep it short and recognizable. |
| MCP Endpoint URL | Yes | The full URL the CMS serves MCP at, for example https://cms.example.com/mcp. |
| Auth | Yes | OAuth or API Key, matching how an administrator configured that endpoint. |
With OAuth, everything is configured for you: click Connect, sign in to the CMS, and authorize access. With API Key, paste the key and save—there is no connect step.
Any MCP server can also be added as a Custom server by URL, including a Brightspot one, but the Brightspot type is the first-class option. See MCP servers.