The connector
Permissions and scope
What an assistant can ever see, what is never exposed, and why.
The connector's ceiling
An MCP connector is the one credential a broker hands out without reading a contract: they paste a URL into Claude and click "Authorize". So the ceiling is not set by the API's full vocabulary, but by what the nine tools actually call:
leads:read leads:write
operations:read operations:write
properties:read
viewings:read viewings:write
offers:read offers:write
documents:read
signatures:read
agents:read
A permission nobody consumes is a permission that can only ever be abused.
What is not exposed, and why
There is no properties:write. Creating a listing is the Publicar flow: the
mandate gate, photo enhancement, per-portal adaptation. A property conjured from
a sentence would be a draft that looks like a listing.
There is no documents:write or signatures:write. Nothing that puts a
signature in front of a client starts from an assistant's guess.
The test is not "can the API do it?" but "is one sentence enough to want it?". Booking a viewing at four o'clock, yes. Sending a mandate, no.
A declared permission is not always enough
When a tool composes several families of data, its declared permission falls short — so it checks the others itself.
buscar is guarded by leads:read but also returns properties: it verifies
properties:read on its own. ver_expediente does the same section by section,
and reports in permisos_faltantes what it removed.
Without that field, a section left empty for lack of permission would be indistinguishable from a genuinely empty one, and the assistant would answer "they have no viewings" about a file that has three.
Two boundaries, held in two different places
The brokerage is held by the database's row policies, backed by an explicit brokerage filter on every query. The connector runs with service credentials, so the policy is not the boundary here: that filter is.
The agent, inside the brokerage, is held by no policy: it is a product rule, the same one the app applies when it renders a screen. The connector applies it to the letter:
| filtered by | |
|---|---|
| leads | assigned agent |
| properties | the listing's agent |
| viewings | the viewing's agent |
| operations | through assigned leads, inside the query |
An owner or an admin is not restricted; a captador, a closer or an assistant sees their own book. Without this, an assistant connected with a captador's consent read the whole agency pipeline — more than the app shows that same person, which is harder to explain than a bug.
An API key (ork_live_…) remains brokerage-scoped: it has no author, the
broker issues it for their agency, and that is what v1 has promised from the
start. See API keys.
mi_jornada and agenda additionally take a alcance (scope): a manager can
ask for the whole house, a restricted agent cannot. The parameter can never
widen beyond the role.