list_users_without_mfa
List Azure AD users who do not have multi-factor authentication (MFA) enabled.
Instructions
Lista usuários sem MFA registrado.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
List Azure AD users who do not have multi-factor authentication (MFA) enabled.
Lista usuários sem MFA registrado.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds no behavioral context beyond restating the tool's name, such as how MFA registration is determined, whether disabled users are included, or any pagination or data-freshness behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly conveys the tool's purpose with no filler or redundant wording. It is appropriately sized for a simple read-only list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list with one optional parameter, the basic action and target resource are clear. However, it lacks details that would help an agent disambiguate from related tools and understand exactly what qualifies as 'MFA registrado', so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for parameter meaning. The only parameter, 'limit', is self-explanatory, but the description does not clarify its semantics such as maximum allowed value, default usage behavior, or how it affects the result set. The schema provides only a default of 100.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Lista') and a specific resource ('usuários sem MFA registrado'), making the tool's core purpose obvious. However, it does not explicitly differentiate it from closely related sibling tools such as list_users_with_weak_authentication or assess_privileged_mfa, leaving potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many similarly named sibling list tools, the agent must infer the intended use case from the name alone, and no conditions, exclusions, or recommended alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.