Skip to main content
Glama
Sign In
entraadm-mcp

entraadm-mcp

by shigechika
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

m365_service_health

Retrieves Microsoft 365 service status per service plus open incidents and advisories, helping correlate sign-in failure spikes with active Entra or Exchange outages.

Instructions

Microsoft 365 service status per service, and the open incidents and advisories.

Two Graph reads (ServiceHealth.Read.All): healthOverviews (one row per service with its current status) and the unresolved serviceAnnouncement/issues, newest first. A sign-in failure spike reads very differently while Entra or Exchange has an open incident, which is why daily_brief carries this section too. Each section degrades on its own ({"error", "missing_permission"}); summary is computed from whatever came back. capped means either collection was cut short by the page budget, so the counts are lower bounds. The message center (messages) needs a different permission and is not read.

Args: max_pages: Page budget for each collection (default: ENTRAADM_MAX_PAGES_DEFAULT). tenant: Tenant to read: a [tenant.] section name or one of its domains (default: the default tenant).

Input Schema

NameRequiredDescriptionDefault
tenantNo
max_pagesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.0
    • addedInput schema / properties / tenant
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Tenant"
+}
  2. Addedv1.3.0

TDQS

A4.6/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: two Graph reads, required ServiceHealth.Read.All permission, ordering (newest first), independent per-section degradation with an {"error","missing_permission"} shape, summary computed from partial results, and capped as a lower-bound flag. It even discloses that message center is deliberately not read.

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

Conciseness4/5

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

Front-loaded with the one-line purpose, then progressively richer detail; every clause (degradation, capped semantics, excluded messages endpoint) adds needed context. Backtick-heavy prose makes it slightly denser than necessary but nothing is filler.

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

Completeness5/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, yet the description covers return structure (per-service rows, issues collection, summary, error sections), partial-failure semantics, and count caveats. An agent has everything it needs to call this and interpret the result.

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?

Schema coverage is 0%, so the description must compensate, and it does for both parameters: max_pages as a per-collection page budget with its default constant, and tenant as a config section name or one of its domains. The default value referencing an opaque ENTRAADM_MAX_PAGES_DEFAULT symbol is the only minor gap.

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

Purpose5/5

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

The opening sentence names a specific resource (Microsoft 365 service status / open incidents and advisories) and a clear scope. It is unmistakable next to read-only log and audit siblings such as signin_logs or directory_audits, and it explicitly ties its role to daily_brief.

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

Usage Guidelines4/5

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

It gives a concrete decision context — a sign-in failure spike reads differently when Entra or Exchange has an open incident — which tells the agent when this matters. It does not state exclusions or an explicit 'use X instead of Y' routing, 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.

Deploy Server

Other Tools