Microsoft Active Directory MCP Server

Overview Schema Source Related Servers Discussions Admin

ad_get_fsmo_roles

Retrieves the current FSMO role holders in Active Directory, helping administrators verify domain and forest operations master assignments.

Instructions

[Domain & Domain Controllers] [READ] Consultar detentores das funcoes FSMO.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ad_get_fsmo_roles"
  }
}

Input Schema

Name	Required	Description	Default
`correlation_id`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 1, 2026

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden, and the only behavioral signal is the bracketed [READ] tag. It does not say what permissions are needed, whether the query is per-domain or per-forest, or which FSMO roles are covered (schema master, RID master, PDC emulator, etc.).

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?

A single short sentence preceded by category and read-only tags: nothing is padded and the resource being queried is front-loaded. The terseness borders on under-specification, but there is no wasted text.

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

Completeness2/5

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

An output schema exists so return values need not be described, and the zero-argument nature lowers the burden. Still, for an unannotated AD tool the description should say whether results are per-domain or forest-wide and which five FSMO roles are returned; none of that is present.

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

Parameters2/5

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

Schema description coverage is 0% and the single optional parameter, correlation_id, is not mentioned at all in the description. The description neither explains the tracing parameter nor clarifies that the tool effectively takes no meaningful input, so it adds nothing over the raw schema.

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?

States a specific verb ('Consultar' / query) and a specific resource ('detentores das funcoes FSMO' / FSMO role holders), plus category tags [Domain & Domain Controllers] and [READ]. This is enough to distinguish it from siblings like ad_get_domain_functional_level or ad_get_forest_info, though it never names those neighbors explicitly.

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

Usage Guidelines2/5

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

There is no statement of when to use this rather than alternatives, no prerequisites, and no exclusions. The [Domain & Domain Controllers] tag implies the general context but gives no routing guidance among ~80 sibling tools.

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

Deploy Server