Privacy and scope

One single company per credential

Every authorisation is pinned to one company from the moment it is issued or authorised. No tool takes the company as a parameter: it takes it from the credential. There is no way to ask a tool for another company’s data, and get_context is how you confirm, before answering anything, which company this connection belongs to.

Membership is revalidated on every call against the companies that person still has assigned as staff — not only when the credential is issued. Removing someone’s staff role in a company cuts off their MCP access to that company at that same instant, with nothing separate to revoke.

Read-only, except for a report request

Out of the 22 tools, 21 are reads. The only exception is request_report, which queues a job to generate an Excel or CSV file. No tool deletes or modifies the company’s data.

Personal data sits behind two independent keys

Names, emails, phone numbers and document numbers do not appear by default. For them to appear, both keys have to be open at once:

1. The deployment’s — the MCP_EXPOSE_PII variable in the hackÜ that answers. It ships off. Turning it on sends corporate clients’ employees’ personal data to whichever model the staff member is using, so it requires that provider to be a declared subprocessor with a signed DPA before you enable it.
2. The credential’s scope — users:pii, granted per person.

Both exist so that a credential can serve aggregate questions or dashboards without ever exposing anyone’s phone number, and so that revoking that reach does not mean revoking the whole integration.

Every answer that can include these fields carries an explicit pii_included: true|false. When it is false, people come back identified by user_id only.

Segmentation narrows things before the answer

If the staff member who authorised the credential is restricted to a segment of the company (segment_restriction), the people tools return only that slice — not the whole company. get_context exposes that limit explicitly, and several answers (list_users, get_company_overview) include a note clarifying that the counts are the segment’s, not the whole company’s. Presenting that figure as if it were the company total is a reading error, not a limit of the data.

Reports go to the person’s email, never to the conversation

request_report does not return the file’s contents. It queues a job, sends the download link to the email of the staff member who asked for it, and that link requires their own hackÜ login to open — the model could not read it even if it wanted to. This is deliberate: a report’s personal data goes through that person’s email and login, never through the chat.

Tip

If a request asks for a report_type outside the valid list (users, users_csv, evaluations, evaluations_detail, surveys, ssaa, point_logs, pensum_users, finished_courses), or if an identical one is already running, hackÜ rejects it — see Troubleshooting.