Privacy and scope

One answer, one company

When you authorise, you choose which companies the connection may read. If you administer one, that is the one. If you administer several, you tick the ones you want and then move between them in the same conversation, without signing in again.

That set is frozen into the credential and cannot be widened from the assistant: asking for a company you did not tick is refused, whether or not it exists. Each call answers about one of them; the server never blends two companies into a single answer.

If the connection covers several and the question does not make clear which one you mean, the server does not choose for you: it replies with the list so the assistant can ask. An answer about the wrong company reads perfectly and warns you of nothing, which is worse than no answer. get_context is how you confirm, before answering anything, which companies this connection reaches.

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. Losing one of five leaves the other four working; losing all of them closes the connection.

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.