Skip to main content
Glama
shigechika

entraadm-mcp

by shigechika

health_check

Check service health and Graph connectivity, verify sign-in log permissions, and return healthy, degraded, or error status so callers know whether Entra ID triage tools can run.

Instructions

Fleet-standard health probe: service/version/status plus two independent Graph probes.

graph confirms Microsoft Graph is reachable at all (GET /users with $top=1 -- needs only User.Read.All, the minimum permission every deployment of this server needs anyway). signin_probe additionally confirms the current credential can read sign-in logs -- the permission every other tool here except get_user depends on. Both probes always run, independently of each other: a tenant that has AuditLog.Read.All but not (yet) the baseline User.Read.All would otherwise have this report "Graph unreachable" -- a fabricated diagnosis, since Graph plainly is reachable if the other probe succeeds. status is derived from the two outcomes: healthy when both succeed, degraded when exactly one does (Graph is reachable but some permission is missing), error only when neither does.

Read-only. Always returns the same keys regardless of outcome (detail is null on success, a translated message on failure), so a caller never has to branch on which keys are present.

sites reports the optional ENTRAADM_SITES_INI table (configured, ranges, error). A configured file that fails to load is an error here and leaves status no better than degraded: without it every internal IP would be reported as an external spray suspect.

With a tenant file (ENTRAADM_CONFIG) every tenant is probed. The top-level keys stay the DEFAULT tenant's, as in a single-tenant deployment, plus tenant (the default's name) and tenants: {name: {default, domains, auth_mode, status, graph, signin_probe}} for every tenant, the default included. Each tenant's probes run under an even share of the call budget (ENTRAADM_DEADLINE), so a tenant that does not answer is an error there instead of stalling the call. Another tenant that is not healthy makes the top-level status at most degraded (the default tenant alone can make it error). arm is the default tenant's only. Env-only results carry neither key.

identity_protection is the Identity Protection licence probe (licensed / not_licensed / no_permission / error, cached per tenant for an hour; see compromise_suspects), per tenant in tenants too. Informational: not_licensed (no Entra ID P2) and the rest never change status.

home_countries reports ENTRAADM_HOME_COUNTRIES (configured, countries, error), which compromise_suspects needs for its foreign-success finding. Informational: unset or invalid never changes status.

arm is a third, informational probe (Azure Resource Manager reachable, and how many subscriptions this credential can see). It never moves status: Azure RBAC is optional for this server, and a deployment used only for Entra triage must not sit at degraded forever because nobody granted it a Reader role. It runs last under its own short budget (_ARM_PROBE_SECONDS) so an unresponsive ARM cannot push this whole call past the client's tool-call timeout. The budget bounds the request, not the first token acquisition (azure-identity is synchronous; in azure-cli mode it shells out to az), which is the same limit every tool here has.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so: it states 'Read-only', explains how 'status' is derived from the two probe outcomes, documents the per-tenant call-budget/deadline trade-off, the one-hour Identity Protection cache, and that a configured-but-broken sites file caps status at degraded. It even explains why the ARM probe runs last under its own budget (tool-call timeout avoidance) — behavior an agent cannot infer from schema or annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with a clear one-line summary and organized by return key, but at roughly 450 words for a zero-parameter probe it is bloated with design rationale ('a fabricated diagnosis, since Graph plainly *is* reachable', 'azure-identity is synchronous') that does not help an agent decide or call correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations exist, so the description must document returns — and it covers status semantics, per-tenant nesting, sites, identity_protection, home_countries and arm in detail. Gaps remain: the contents of the top-level 'service' and 'version' keys, and the shape of 'detail' messages, are never described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the baseline of 4 applies; nothing in the schema needs elaboration beyond the environment variables (ENTRAADM_CONFIG, ENTRAADM_SITES_INI, ENTRAADM_DEADLINE, ENTRAADM_HOME_COUNTRIES) the description helpfully names as implicit inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names the specific verb and output ('Fleet-standard health probe: service/version/status plus two independent Graph probes'), so an agent knows exactly what it returns. It does not, however, distinguish itself from the sibling 'm365_service_health', which an agent could easily confuse with this server-side probe.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the probe's purpose (confirming Graph reachability, baseline permissions, optional licence/config availability) suggests calling it when diagnosing configuration or permission failures, but there is no explicit 'use this when' statement and no exclusion against m365_service_health or daily_brief.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.