Skip to main content
Glama
entraadm-mcp

entraadm-mcp

by shigechika

audit_log_search_start

Submit an asynchronous Microsoft Purview audit log search to see what a session did after sign-in, such as files downloaded, mailbox rules, or directory changes. Returns a query_id to poll for results.

Instructions

Start a Microsoft Purview audit log search: what was done in OneDrive/SharePoint, Exchange, Entra.

The follow-up to a confirmed takeover: the sign-in log shows which resources a session obtained tokens for, this shows what it then did (files opened or downloaded, mailbox rules and cmdlets, directory changes). A search runs asynchronously in Microsoft 365 and usually takes several minutes, so this only submits it (Graph POST /security/auditLog/queries) and returns query_id; call audit_log_search_result with that id (and the same tenant) until done is true.

The call creates a saved audit search object in the tenant (listed in the Purview audit search page); it changes no directory, mailbox or file data. Each call counts against the tenant's audit search limits (searches per day, searches running at once): a 429 comes back as rate_limited: true and is not retried. At least one filter besides the window is required, so a call never searches the whole tenant's log. The filters combine with AND.

Needs the application permission AuditLogsQuery.Read.All, or the service-scoped AuditLogsQuery-OneDrive.Read.All / -SharePoint.Read.All / -Exchange.Read.All / -Entra.Read.All (then set service to match). A 403 returns missing_permission. created is true, false (nothing was created), or null (the answer was lost; a search may exist anyway).

Args: user: Only records of this userPrincipalName. hours: How far back from end (or now) to search, clamped to [1, 4320] (180 days). Ignored with start. start: Window start, ISO 8601 with an offset (e.g. 2026-10-21T22:00:00+09:00). end: Window end, ISO 8601 with an offset (default: now). record_types: auditLogRecordType values, e.g. ["sharePointFileOperation", "exchangeItem"]. operations: Operation names, e.g. ["FileDownloaded", "New-InboxRule", "MailItemsAccessed"]. ip_addresses: Client IPv4/IPv6 addresses. keyword: Free text matched against the workload-specific content of each record (auditData), not against indexed properties such as the operation name; use operations for those (at most 256 characters). service: One workload, e.g. "Exchange", "SharePoint", "OneDrive", "AzureActiveDirectory". object_ids: Object ids, e.g. a file URL or a mailbox item id. tenant: Tenant to search: a [tenant.] section name, one of its domains or its tenant id (default: the tenant claiming the user's domain, else the default tenant).

Input Schema

NameRequiredDescriptionDefault
endNo
userNo
hoursNo
startNo
tenantNo
keywordNo
serviceNo
object_idsNo
operationsNo
ip_addressesNo
record_typesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.10.1

TDQS

A4.9/5.0
Behavior5/5

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

No annotations exist, and the description fully carries the burden: it discloses the side effect (a saved audit search object is created in the Purview audit search page, but no directory/mailbox/file data changes), the async multi-minute latency, rate-limit behavior (429 surfaces as rate_limited and is not retried), the required permission plus service-scoped alternatives, 403 as missing_permission, and the tri-state meaning of the created flag including the ambiguous null case.

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 purpose and the required follow-up call before diving into side effects and permissions, with an Args block for per-parameter detail. It is long, but nearly every sentence carries information an agent needs given zero schema documentation; the investigative framing in the second paragraph is the only somewhat expendable part.

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?

Given 11 parameters, no annotations, no output schema and 0% schema coverage, the definition supplies everything needed to invoke correctly: return value (query_id), polling protocol, error-to-flag mappings, permission requirements, and a filter-combination rule (AND). Nothing material is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it documents all 11 parameters with semantics the names do not convey: hours is clamped to [1, 4320] and ignored when start is set, start/end require ISO 8601 with offset, keyword matches workload content (auditData) rather than indexed properties and caps at 256 chars, tenant falls back to the domain-claiming tenant, and record_types/operations/service come with concrete value examples.

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 ('Start a Microsoft Purview audit log search') and immediately scopes the workloads (OneDrive/SharePoint, Exchange, Entra). It is clearly separable from siblings like signin_logs and audit_log_search_result, the latter named explicitly as the consumer of this tool's output.

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

Usage Guidelines5/5

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

Explicitly states when this applies ('the follow-up to a confirmed takeover: the sign-in log shows which resources a session obtained tokens for, this shows what it then did') and gives the exact follow-up procedure: call audit_log_search_result with the returned query_id and same tenant until done is true. It also states the precondition that at least one filter beyond the window is required, so a whole-tenant sweep is impossible.

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