Connect Claude to Microsoft Entra ID

List the people in the tenant, with the properties named in `select`. This is the entry point for the user side: get_user, list_group_members and the role-assignment reads all key on the id returned here. `filter` takes a simple OData expression - "accountEnabled eq false", "userType eq 'Guest'", "startsWith(displayName,'Jane')" - but not endsWith or $search, because this connector does not send the ConsistencyLevel header that Graph's advanced query requires. Page with the @odata.nextLink Graph returns rather than an offset.

Fetch one person by object id or userPrincipalName, with the properties named in `select`. Graph accepts an address such as [email protected] here as well as a GUID, so this is the way to resolve a sign-in name without a list first. `accountEnabled` false means the account is blocked from signing in.

List the tenant's groups with their id, name, description and type. The combination of `groupTypes`, `securityEnabled` and `mailEnabled` is what distinguishes a Microsoft 365 group from a plain security group; a group with 'DynamicMembership' in groupTypes has its membership computed from a rule rather than assigned. Groups carry application and resource access, so this is the map of what is granted in bulk before any individual is looked at.

Fetch one group by object id, with its name, description, type and membership rule. Read it to confirm which group an id refers to before calling list_group_members, which returns the people in it.

List the direct members of one group. Members can be users, other groups, devices or service principals, so each entry carries an @odata.type saying which it is. Membership is direct only - a person who is in a nested group appears under that group rather than here.

List the app registrations in the tenant - the applications this directory owns, as opposed to the service principals that represent them. Each carries its appId, display name, sign-in audience and requested permissions. Read it to answer "what have we registered" and to find the appId that a sign-in log entry names. Client secrets and certificates are never returned in plaintext by Graph, and no operation here returns one.

List the service principals in the tenant - the local identity of every application that can sign in here, including third-party apps somebody consented to and managed identities Azure created. This is the surface an access review actually cares about: an app registration is a definition, a service principal is a thing with permissions. `appOwnerOrganizationId` different from your own tenant id marks a multi-tenant app from someone else. Withheld from the audit log because a managed identity or an enterprise app is frequently named after the person or the resource it acts for.

List the directory roles that are activated in the tenant, with each one's id, display name, description and roleTemplateId. Only activated roles appear - a role nobody has ever been assigned may be missing entirely, which is Entra's behaviour and not an error. The `id` returned here is a directory role instance; list_role_assignments keys on roleDefinitionId, which for a built-in role is the same GUID as roleTemplateId. $filter supports `eq` only.

List who holds which directory role. Each assignment pairs a principalId with a roleDefinitionId and a scope, and `expand: principal` resolves the principal into the user, group or service principal it names - which is what turns a list of GUIDs into the answer to "who are our Global Administrators". Filter by roleDefinitionId to ask about one role (62e90394-69f5-4237-9190-012177145e10 is Global Administrator) or by principalId to ask about one person. Withheld from the audit log: this is the list of named people holding privileged access.

Read the tenant's sign-in logs - who signed in, from which IP address and location, on which device, to which application, and whether it worked. This is the operation to reach for after a suspicious sign-in alert. Always pass a `filter` with a time range or Graph times the request out: "createdDateTime ge 2026-08-01T00:00:00Z and createdDateTime le 2026-08-07T23:59:59Z". Other filterable properties are userId, userPrincipalName, appId, appDisplayName, status/errorCode, ipAddress, clientAppUsed and riskLevelDuringSignIn. Only $filter, $top and $skiptoken are supported - no $select and no $orderby - and only the retention window Entra keeps is available. The response is named employees, their addresses and their locations, so it is never written to the audit log.

List the devices registered in the directory, with each one's display name, operating system and version, trust type, compliance and management state, and when it was last seen. Use it to answer "is this laptop enrolled and compliant" and to find the deviceId a sign-in log entry names. `trustType` is AzureAd for a joined device, ServerAd for a hybrid-joined one and Workplace for a registered personal device. A device record is named after the employee who uses it, so the response is withheld from the audit log.

Read the tenant's own record - display name, verified domains, country, directory size limit and creation date. It takes no arguments and needs only Organization.Read.All, so it is the cheapest call that proves the app registration, the client secret and the admin consent are all actually in place, which is why an install runs it to test itself. It describes the tenant rather than anybody in it, so unlike most reads here its response is kept in the audit log.