orkasa

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
leadsassigned agent
propertiesthe listing's agent
viewingsthe viewing's agent
operationsthrough 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.