What is a connector?
A connector is a link, carrying a credential, that exposes a Digital FTE to an external AI assistant as an MCP server. With it, a manager can ask their own assistant, in Claude or ChatGPT, what the Search Visibility FTE has waiting, what its citation measurement shows, or to preview a draft, and can approve or send back from there, with the same gates in place as in the workspace.
The term is the platform's own. MCP is the open protocol the assistants speak; the connector is the organization's credentialled endpoint for one FTE that speaks it.
How does a connector work on ftes.ai?
A permissioned user mints a connector from the workspace. The platform returns a URL that carries the credential, exactly once: no read endpoint reproduces it afterwards, and a lost link is rotated, producing a new credential and invalidating the old, rather than recovered. The user pastes the URL into their assistant's connector settings, and the assistant can then call the FTE's tools.
The connector's public origin comes from the platform's configuration, never from the request that minted it, because neither assistant can reach a local address and a proxied request's host is the internal one. Minting, rotation, and revocation are all logged.
Why do the gates still apply?
The gates still apply because the assistant is a client of the FTE, not a bypass of it. When a manager approves a draft through their assistant, the assistant calls the same approval action the workspace would, and the approval is logged with the manager's name. Approving publishes to the real site and cannot be undone, so the assistant is instructed to preview before approving and never to approve anything the manager has not just asked it to.
The always-escalate and never-automated lists apply identically. A connector does not add a way around them; it adds a place to exercise the same decisions.
- Read: brief, approvals, pipeline, library, visibility, detections
- Act within bounds: approve after preview, send back, start a production run
- Never: anything the gates would refuse in the workspace
Why is the credential shown only once?
Because a credential that can be re-read is a credential that can be read by the wrong person. Returning it once and rotating on loss means the platform never stores it in a retrievable form, the audit trail shows every mint and rotation, and a compromised link is invalidated by the person who notices rather than left live. It is the same standard applied to every credential on the platform.
For the user it means one habit: paste it into the assistant immediately, and if it is lost, rotate rather than search.
What is a connector often confused with?
It is confused with an integration, which is a connection from the FTE outward to a tool it works in; a connector is a connection inward, from an assistant to the FTE. It is confused with an API key for the platform; it is scoped to one FTE and one organization. And it is confused with giving the assistant autonomy; the assistant can only do what the manager could do in the workspace, under the same gates.
It is sometimes assumed to expose data broadly. It exposes one FTE's work to the assistant of the person who minted it, and it can be revoked in one action.
Where do you see connectors?
In the FTE's Setup tab, where connectors are minted, rotated, and revoked, and in the audit trail, which records each action. The assistant's own settings hold the pasted URL. The MCP connector specifications on the platform describe the tools exposed.
Related terms: credential, approval gate, integration, revocation, MCP.
A practical habit is to mint the connector for the person who will actually use it, in their own session, and to revoke it the day they stop. Because the credential is scoped to one FTE and shown once, the cost of a fresh connector is a minute, and the cost of a stale one that nobody remembers is the kind of risk the once-only rule exists to prevent.