Permissions

Every authorisation carries an explicit list of scopes: six permissions, no more. Each tool declares the permission it needs; if the authorisation does not carry it, hackÜ answers 403 and the tool refuses. Adding a new tool never widens what a credential can read on its own.

The 6 scopes

Scope	Label	What it unlocks
`users:read`	List users	The company roster, one person at a time, the ranking and the bulk uploads.
`users:pii`	See names, emails and phone numbers	Makes the answers that already return people include their identifiable data, instead of just the `user_id`. It does not open any new tool on its own.
`courses:read`	Query the course catalogue	The company’s course catalogue and the detail of one course, with its modules.
`communications:read`	Query communications and their deliveries	The communications prepared or sent, and what happened with each recipient.
`learning:read`	Query evaluations, surveys and pensums	Challenges, surveys, evaluations, attempts and pensums — the bulk of the tools.
`reports:generate`	Request reports in Excel or CSV and see the ones already generated	Seeing the reports already requested, and requesting a new one.

get_context asks for no scope at all: it describes the credential itself (which company it belongs to, on whose behalf, with what limits), and anyone who can authenticate already has the right to know that.

`users:pii` is different from the rest

The other five scopes open or close an entire tool. users:pii opens none: it changes what is already returned by list_users, get_user and list_communication_deliveries, adding a name, email, phone number or document number to rows that would otherwise only carry an id.

This is deliberate, in the model’s own words:

USERS_PII is separate from USERS_READ on purpose. Whether a deployment may return personal data is a configuration decision; whether a given credential receives it is a per-person decision. Both have to say yes.

In practice this means two independent keys, not one: the deployment’s (MCP_EXPOSE_PII, see Privacy and scope) and the credential’s scope. Every answer that may carry personal data includes pii_included: true|false so it is explicit which of the two modes you are looking at — you should never assume it from the result.

Which tools ask for each scope

users:read (5): get_company_overview · list_ranking · list_bulks · list_users · get_user

courses:read (2): list_courses · get_course

communications:read (3): list_communications · get_communication · list_communication_deliveries

learning:read (9): list_challenges · list_surveys · get_survey_results · list_evaluations · list_evaluation_attempts · get_evaluation_attempt · list_pensums · get_pensum · list_pensum_enrolments

reports:generate (2): list_reports · request_report

No scope (1): get_context

5 + 2 + 3 + 9 + 2 + 1 = 22 tools — exactly the total the server exposes.

The only one that is not a read

Out of the 22, request_report is the only one that is not a read. It writes a row and queues a background job; everything else on this server is a query. That is why it lives behind its own scope, reports:generate, instead of sharing users:read or another read scope — granting that action has to be a separate decision from granting visibility.