Skip to main content
Glama
shigechika

entraadm-mcp

by shigechika
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

vm_activity

Investigates Azure VM activity logs over a time window to show who operated the VM and which events Azure raised, helping determine whether a restart was user- or platform-initiated.

Instructions

What happened to an Azure VM in a time window: operations people ran, and events Azure raised.

Azure Resource Manager in the DEFAULT tenant only, also when several tenants are configured (ENTRAADM_CONFIG).

Answers "did someone restart this VM, or did Azure?" from the Azure activity log of the VM's subscription. Read-only; needs the Reader role on the subscription. Two reads: the VM's resource group (server-side filter, so a busy subscription cannot crowd the VM's own events out of the page budget) feeds health and vm_operations; the whole subscription feeds the rest.

  • health: Resource Health events of the VM (cause PlatformInitiated = Azure, e.g. Redeploying due to host failure; UserInitiated = an operation on the VM, or Reboot initiated from inside the machine for a restart from the guest OS).

  • vm_operations: Administrative events on the VM and its sub-resources (restart, deallocate, redeploy, extension changes), with caller (a user principal name or an application id). One operation usually logs several events (Started, Accepted, Succeeded) sharing a correlation_id.

  • other_operations: Administrative events on any other resource of the subscription (count of events, operations = distinct correlation ids, items = the newest 50). Zero here and in vm_operations means nobody operated the subscription through Azure Resource Manager in the window; it says nothing about actions inside the guest OS.

  • service_health: Azure incidents and planned maintenance announced to the subscription.

  • other_categories: counts of the remaining categories (Alert, Policy, other resources' health events, ...).

vm is the VM name, matched case-insensitively across the subscriptions this credential can see; narrow it with subscription (id or display name from list_subscriptions) or resource_group when the name is not unique (ambiguous lists the candidates). A single match found while some subscription could not be listed completely is not taken as unique: it comes back as candidates with search_complete: false, to be confirmed by naming its subscription. Naming the subscription also keeps the search short: without it every visible subscription is listed, and the search may use at most half of the call's time budget. The window is start..end (ISO timestamps with an offset, e.g. 2026-10-21T21:00:00+09:00; seconds may be omitted), or the hours before end (default 24; end defaults to now); at most 168 hours, within the 90 days the activity log keeps. Times in the result are UTC as Azure returns them. capped marks a read cut short by the page or time budget (capped_reads says which): then an empty section is not proof that nothing happened.

Input Schema

NameRequiredDescriptionDefault
vmYes
endNo
hoursNo
startNo
max_pagesNo
subscriptionNo
resource_groupNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.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 so: states it is read-only, requires the Reader role, operates only in the DEFAULT tenant even when several are configured, and explains the dual-read strategy, page/time budgets, the 'capped'/'capped_reads' markers, and the critical caveat that an empty section is not proof nothing happened.

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?

The headline answers are front-loaded and the bulleted breakdown of return sections is easy to scan. It is long and the tenant/search-completeness discussion is dense, but nearly every sentence adds operational value rather than repeating the schema.

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 exists, yet the description documents each returned section (health causes, vm_operations with caller and correlation_id, other_operations counts and truncation to 50, service_health, other_categories) plus the truncation flags. An agent has enough to call the tool and interpret results correctly.

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?

At 0% schema coverage this description must compensate, and it largely does: explains vm name matching (case-insensitive, ambiguity via 'ambiguous'/'candidates'/'search_complete'), subscription and resource_group narrowing, the start/end/hours relationship with defaults, the 168-hour/90-day limits, and ISO offset format. The one gap is max_pages, which is never named or explained despite the repeated 'page budget' references.

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?

Opens with a specific verb+resource+scope: 'What happened to an Azure VM in a time window: operations people ran, and events Azure raised.' It is clearly distinguishable from siblings like vm_backup_status or health_check, and the 'did someone restart this VM, or did Azure?' line pins the intent down further.

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?

Gives a concrete scenario ('did someone restart this VM, or did Azure?') and tells the agent to use list_subscriptions to source the subscription identifier, plus when to add subscription/resource_group. It does not explicitly say when to prefer a sibling tool instead, which keeps it below 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