This server provides read-only Entra ID security investigation tools for identity incidents, account risk, sign-ins, directory audits, and Conditional Access coverage.
get_user_context — retrieve a user's profile, groups, directory roles, and privileged role status to assess incident severity.
get_user_signins — fetch recent sign-in events with aggregated stats (successes, failures, distinct IPs/locations) and security notes.
get_risky_users — list Entra Identity Protection risky users, filtered to active at-risk or confirmed-compromised accounts.
get_risk_detections — get granular risk detection reasons (leaked credentials, anonymized IP, etc.) for a user or tenant.
get_directory_audits — review recent admin directory changes, flagging sensitive/persistence or privilege-escalation operations.
get_conditional_access_policies — list CA policies with real enforcement state to explain blocks or coverage gaps.
All tools are read-only; some require Entra ID P1/P2 licenses.
Provides access to VirusTotal threat intelligence, enabling security analysts to enrich investigations with reputation data on files, URLs, domains, and IP addresses.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Entra ID SecOps MCP Server Investigate recent sign-ins and risk detections for user@contoso.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that exposes Microsoft Entra ID security logs as tools executable by an AI agent (Claude Desktop, Cursor, or any other MCP client).
Goal: allow an analyst to ask a question in natural language — "why can't this account sign in anymore?" — and get an answer in seconds based on the tenant's actual data.
📖 Installation and testing guide — the three ways to launch the server, step by step. 🔍 Technical brief — market scan and secure exposure.
A raw Microsoft Graph response contains about sixty fields per event. The server applies aggressive truncation: only about a dozen security indicators reach the model. This is both a cost optimization (factor ~35 on tokens) and a security control, since unlisted fields — some of which are attacker-controlled — never enter the context.
Aggregates (number of failures, distinct IPs, suspicious patterns) are computed in Python, not inferred by the model.
Related MCP server: Microsoft Sentinel Data Exploration
Tool | Purpose | Graph Permission | License |
| Account record: position, groups, held roles. Determines the severity of an incident. |
| — |
| Recent sign-ins for a UPN, with summary and suspicious patterns |
| P1 |
| Accounts flagged as risky by Identity Protection |
| P2 |
| Individual detections: why an account is at risk |
| P2 |
| Administrative changes; flags persistence actions |
| — |
| Active policies and coverage gaps |
| — |
All tools are read-only: the server never modifies the tenant.
get_user_context le compte est-il privilégié ? l'incident est-il grave ?
↓
get_user_signins que s'est-il passé sur l'authentification ?
↓
get_risk_detections qu'a détecté Identity Protection, et pourquoi ?
↓
get_directory_audits l'attaquant a-t-il modifié quelque chose une fois entré ?This sequence is also described in the server's instructions, which the MCP client sends to the model.
The fixture mode replays a demo incident and requires no tenant, license, or secret.
python -m venv venv
venv/Scripts/activate # Windows ; sur Linux/macOS : source venv/bin/activate
pip install -e ".[dev]"
cp .env.example .env # ENTRA_DATA_SOURCE=fixture est déjà la valeur par défaut
python -m entra_secops_mcpCreate an App Registration in the Entra portal.
Add the application permissions from the table above, then grant admin consent.
Generate a client secret.
Fill in .env:
AZURE_TENANT_ID=...
AZURE_CLIENT_ID=...
AZURE_CLIENT_SECRET=...
ENTRA_DATA_SOURCE=graphLicense required. Accessing sign-in logs via the API requires an Entra ID P1 license, and Identity Protection tools require P2. Without them, Graph returns
403. The other tools work without a paid license. Check the tenant's license before you start: this is the classic blocker that wastes several days.
No secret is present in the code or in the Docker image. They are injected at startup via --env-file.
.env is excluded from git by .gitignore. A secret pushed to a repository must be revoked in Azure, not just deleted from the file.
Logging goes to stderr: in stdio transport, stdout carries the JSON-RPC protocol and tolerates no stray bytes.
All variables are documented in .env.example.
docker build -t entra-secops-mcp .
docker run -i --rm --env-file .env entra-secops-mcpFinal image: 277 MB, multi-stage build, runs as a non-root user (uid=1000), no secrets in the layers.
-i keeps standard input open — that's where the MCP protocol passes through. No -t: a pseudo-terminal injects color codes that corrupt JSON frames.
pytest # 81 tests
ruff check src tests
mypy src # mode strict
pre-commit install # contrôles avant chaque commit
python demo.py # investigation de démonstrationTools | 6, all read-only |
Tests | 81, no Azure tenant required |
Types |
|
MCP Protocol |
|
Container | verified via a real MCP client: startup 2.4 s, tool call ~110 ms |
MIT.
Liste les politiques d'accès conditionnel du tenant, avec leur état réel d'application.
À utiliser pour expliquer pourquoi une connexion a été bloquée (code 53003), ou pour repérer une faille de couverture : politique désactivée, politique en mode audit seul, ou exclusion qui permet à un compte de contourner un contrôle.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Nombre maximum de politiques. Défaut 25, borné à 100. |
| Name | Required | Description |
|---|---|---|
| notes | No | Observations calculées. |
| disabled | Yes | Politiques désactivées. |
| enforced | Yes | Politiques réellement appliquées. |
| policies | Yes | Politiques du tenant. |
| report_only | Yes | Politiques en mode audit, donc sans effet de blocage. |
| total_policies | Yes | Nombre de politiques retournées. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context by promising the 'état réel d'application' and listing the specific coverage-failure states it can reveal. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first announces the action and scope, the second gives concrete use cases. No filler or redundant restatement of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema covers return structure, the single parameter is fully documented in the schema, and annotations cover behavior. The description supplies the missing contextual layer: why the agent would need this tool and what insights it provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single optional limit parameter already has an explicit description with default and maximum. The tool description adds no new param detail, so the default baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Liste') and resource ('politiques d'accès conditionnel du tenant') and adds a distinguishing property ('état réel d'application'). This clearly separates it from the more user-centric sibling tools such as get_user_signins or get_risk_detections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: to explain a blocked connection with error code 53003 or to detect coverage gaps caused by disabled policies, audit-only mode, or exclusions. It does not explicitly name alternatives or say when not to use it, but the use cases are strong and concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère les modifications administratives récentes de l'annuaire, afin d'identifier une dérive de configuration ou un changement non autorisé.
Signale automatiquement les opérations à valeur de persistance ou d'élévation de privilèges : attribution de rôle, ajout d'un secret applicatif, enrôlement d'une méthode MFA, modification d'une politique d'accès conditionnel.
À utiliser après avoir constaté une connexion suspecte, pour déterminer ce que l'attaquant a fait une fois entré.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | Fenêtre de recherche en heures. Défaut 24, borné à 168. | |
| limit | No | Nombre maximum d'entrées. Défaut 25, borné à 100. | |
| initiated_by | No | UPN de l'auteur des modifications, pour ne retenir que ses actions. Omettre pour balayer toutes les modifications du tenant. |
| Name | Required | Description |
|---|---|---|
| notes | No | Observations calculées. |
| entries | Yes | Entrées, de la plus récente à la plus ancienne. |
| failures | Yes | Opérations en échec. |
| window_hours | Yes | Fenêtre temporelle appliquée, en heures. |
| total_entries | Yes | Nombre d'entrées retournées. |
| sensitive_entries | Yes | Entrées jugées sensibles du point de vue de la sécurité. |
| distinct_initiators | Yes | Auteurs distincts observés. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool safe (readOnlyHint, idempotentHint, destructiveHint=false). The description adds meaningful behavioral context—that the tool automatically flags persistence or privilege-escalation operations such as role assignments, app secret additions, MFA enrollment, and conditional access changes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core action and purpose, the second adds high-value behavioral specifics, and the third gives usage guidance. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only three optional parameters, a rich annotation set, and an output schema, the description is complete. It covers what the tool does, what it highlights, and when to use it. Nothing critical is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents hours, limit, and initiated_by with defaults and bounds. The description does not add further parameter-level meaning, which matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Récupère les modifications administratives récentes de l'annuaire'. It also states the investigative purpose (identify configuration drift or unauthorized change), which clearly distinguishes it from sibling tools that focus on user context, sign-ins, or risk detections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives an explicit trigger condition: 'À utiliser après avoir constaté une connexion suspecte, pour déterminer ce que l'attaquant a fait une fois entré.' This provides clear context for when to invoke the tool. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère les détections de risque unitaires : identifiants divulgués, IP anonymisée, voyage impossible, pulvérisation de mots de passe.
C'est l'outil qui explique POURQUOI un compte est signalé à risque, là où
get_risky_users se contente de dire QUE le compte l'est.
Nécessite une licence Entra ID P2.
| Name | Required | Description | Default |
|---|---|---|---|
| upn | No | UPN à cibler. Omettre pour obtenir les détections de tout le tenant. | |
| hours | No | Fenêtre de recherche en heures. Défaut 24, borné à 168. | |
| limit | No | Nombre maximum de détections. Défaut 25, borné à 100. |
| Name | Required | Description |
|---|---|---|
| notes | No | Observations calculées. |
| detections | Yes | Détections, de la plus récente à la plus ancienne. |
| distinct_types | Yes | Types de détection distincts observés. |
| distinct_users | Yes | UPN distincts concernés. |
| total_detections | Yes | Nombre de détections retournées. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds valuable context beyond annotations by listing risk detection categories and the Entra ID P2 license requirement. It does not over-explain but gives meaningful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: what the tool returns, how it differs from the sibling, and a hard prerequisite. The content is front-loaded and there is no filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, full parameter documentation, and output schema, the description covers everything an agent needs: purpose, scope, alternative routing, and licensing. There are no critical gaps for invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already having a clear description and defaults. The tool description does not add parameter-level meaning, but it does not need to; the schema carries the full burden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Récupère') and a precise resource ('détections de risque unitaires'), and lists concrete examples (identifiants divulgués, IP anonymisée, voyage impossible, pulvérisation de mots de passe). It also explicitly differentiates itself from get_risky_users by explaining WHY versus THAT, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It directly positions the tool against get_risky_users: use this one to understand the reason behind a risk flag, while get_risky_users only indicates the flag exists. It also states a key prerequisite, 'Nécessite une licence Entra ID P2', giving the agent an explicit condition for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste les comptes signalés à risque par Entra Identity Protection, du plus risqué au moins risqué.
À utiliser pour obtenir une vue d'ensemble de l'exposition du tenant, ou pour confirmer qu'un compte précis est bien considéré comme compromis.
Nécessite une licence Entra ID P2.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Nombre maximum de comptes retournés. Défaut 25, borné à 100. | |
| only_active | No | Si vrai (défaut), ne retourne que les comptes encore à risque (atRisk, confirmedCompromised) et écarte ceux déjà remédiés ou classés. |
| Name | Required | Description |
|---|---|---|
| notes | No | Observations calculées. |
| users | Yes | Comptes, du plus risqué au moins risqué. |
| high_risk | Yes | Comptes au niveau de risque « high ». |
| active_risk | Yes | Comptes encore à risque (atRisk ou confirmedCompromised). |
| medium_risk | Yes | Comptes au niveau de risque « medium ». |
| total_users | Yes | Nombre de comptes retournés. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context: a required Entra ID P2 license, the risk-ordering behavior, and the scope of accounts returned. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: main action in the first sentence, use cases in the second, and a prerequisite in the third. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter read-only tool, full schema coverage, and an output schema, the description is complete enough. It covers purpose, ordering, use cases, and licensing without needing to duplicate schema information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both parameters are already well documented in the schema, including defaults and allowed range. The description does not add additional parameter-level meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists accounts flagged as risky by Entra Identity Protection, sorted from most to least risky. It is specific about the resource and action, though it does not explicitly name sibling tools for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: to get an overview of tenant exposure or to confirm a specific account is considered compromised. It provides clear usage context, but does not mention exclusions or alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère la fiche d'identité d'un compte : poste, département, état, groupes d'appartenance et rôles d'annuaire détenus.
C'est l'outil qui détermine la GRAVITÉ d'un incident. Une connexion suspecte sur un compte sans privilège et sur un compte administrateur global appellent des réponses très différentes.
À appeler systématiquement avant de conclure sur un incident.
| Name | Required | Description | Default |
|---|---|---|---|
| upn | Yes | User Principal Name complet, par exemple « alice@contoso.com ». |
| Name | Required | Description |
|---|---|---|
| notes | No | Observations calculées. |
| groups | No | Groupes d'appartenance. |
| created | No | Date de création du compte. |
| job_title | No | Intitulé de poste. |
| object_id | Yes | Identifiant d'objet Entra. |
| user_type | No | Member ou Guest. |
| department | No | Département. |
| display_name | No | Nom affiché. |
| is_privileged | Yes | Le compte détient-il au moins un rôle à privilèges ? |
| account_enabled | No | Le compte est-il actif ? |
| directory_roles | No | Rôles d'annuaire détenus. |
| privileged_roles | No | Sous-ensemble des rôles à privilèges élevés. |
| user_principal_name | Yes | UPN du compte. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the context that this tool is authoritative for severity and that it returns identity attributes, but it doesn't disclose additional behavioral details such as staleness, data-source scope, or potential edge cases. With annotations handling the core safety traits, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the action and resource, then adds two purposeful sentences about severity and systematic use. It is concise and every sentence contributes meaningful guidance. The only minor issue is that the severity phrasing is slightly redundant with the usage instruction, but this is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a rich output schema and strong annotations, the description is complete: it explains what the tool returns, why it matters, and exactly when to invoke it. Nothing essential is missing for an agent to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the upn parameter already has a clear explanation with an example. The description adds no extra parameter semantics, but the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Récupère la fiche d'identité d'un compte' and enumerates the exact fields returned (poste, département, état, groupes, rôles). It also distinguishes itself from siblings by framing the tool as the one that determines incident severity, so an agent can clearly tell it apart from sign-in or risk-detection tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong usage direction: it should be called 'systématiquement avant de conclure sur un incident' and explains why severity depends on account privileges. It lacks explicit when-not-to-use guidance or named alternativatives, so it doesn't quite reach a 5, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère les connexions récentes d'un utilisateur pour investiguer un blocage d'authentification, une anomalie géographique ou une compromission.
Retourne les événements réduits à leurs indicateurs de sécurité, plus une synthèse chiffrée (nombre d'échecs, IP distinctes, observations calculées).
Args: upn: User Principal Name complet, par exemple « alice@contoso.com ». hours: Fenêtre de recherche en heures. Défaut 24, maximum 168 (7 jours). limit: Nombre maximum d'événements retournés. Défaut 25, maximum 100.
| Name | Required | Description | Default |
|---|---|---|---|
| upn | Yes | User Principal Name complet, par exemple « alice@contoso.com ». | |
| hours | No | Fenêtre de recherche en heures. Défaut 24, borné à 168 (7 jours). | |
| limit | No | Nombre maximum d'événements retournés. Défaut 25, borné à 100. |
| Name | Required | Description |
|---|---|---|
| upn | Yes | UPN interrogé. |
| notes | No | Observations calculées automatiquement, à vérifier par l'analyste. |
| events | Yes | Événements, du plus récent au plus ancien. |
| failures | Yes | Nombre d'échecs. |
| successes | Yes | Nombre de connexions réussies. |
| total_events | Yes | Nombre d'événements retournés. |
| window_hours | Yes | Fenêtre temporelle réellement appliquée, en heures. |
| distinct_locations | Yes | Géolocalisations distinctes observées. |
| distinct_ip_addresses | Yes | Adresses IP source distinctes observées. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses that events are reduced to security indicators and that a quantitative summary (failure counts, distinct IPs, computed observations) is returned. This is useful behavioral context, though it does not discuss rate limits or response edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and output behavior are front-loaded and each substantive sentence earns its place. The Args block is somewhat redundant with the input schema, but it is compact and does not make the description overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema and annotations, the description provides enough context for correct selection and invocation: purpose, use cases, output shape, and parameter defaults. It could be slightly more complete by pointing to a sibling tool for related risk data, but this is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters, including defaults and bounds, so coverage is 100%. The description largely repeats this information (upn example, hours default/max, limit default/max) and adds no new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent user sign-ins ('Récupère les connexions récentes d'un utilisateur') for authentication-block, geographic-anomaly, or compromise investigations. It uses a specific verb+resource, but does not explicitly contrast itself with siblings such as get_risk_detections or get_user_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete investigative scenarios: 'pour investiguer un blocage d'authentification, une anomalie géographique ou une compromission'. There is no explicit when-not-to-use guidance or named alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_conditional_access_policiesget_directory_auditsget_risk_detectionsget_risky_usersget_user_contextget_user_signinsEach tool targets a distinct data source: user identity context, sign-in events, risky user aggregates, individual risk detections, directory audit logs, and conditional access policies. The closely related risky-user and risk-detection tools are explicitly differentiated by scope, so an agent can reliably pick the right one.
All tool names follow a consistent get_<resource> pattern using snake_case: get_user_context, get_user_signins, get_risky_users, get_risk_detections, get_directory_audits, get_conditional_access_policies. The naming convention is uniform and predictable.
Six tools is a tightly scoped set for an Entra ID SecOps investigation server. Each tool covers a necessary aspect of incident investigation without redundancy or bloat.
The tool surface covers the main investigative workflow: identify the user's privilege level, inspect sign-ins, review identity risk, understand specific risk detections, check for malicious directory changes, and evaluate conditional access impacts. No significant operational gap is apparent for the stated SecOps purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Official Microsoft MCP Server to query Microsoft Entra data using natural language
Find relevant security data from Sentinel data lake for building effective agents. More:aka.ms/s/de
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Read-only finance and operations controls for AI agents with evidence and safe next actions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sultan-zd/mcp-entra-secops'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
