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

The description adds key behaviors not in annotations: the requirement of a delegated token, eligibility check, and bounded activation window. These supplement the annotation flags (readOnlyHint=false, idempotentHint=false) with meaningful operational context. It does not contradict any annotation.

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 two concise sentences that front-load the core action and include a practical example plus a critical prerequisite. Every clause adds information, with no redundant fillers.

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?

Despite being informative, the description lacks parameter-level guidance and does not mention what the response looks like or how to specify duration/justification. For a tool with four parameters and no output schema, this description is not fully sufficient for an agent to invoke it correctly without additional probing.

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?

With 0% schema description coverage, the description carries full responsibility for clarifying parameters, but it does not explicitly map any parameter names. It hints at 'bounded window' (likely duration) and 'eligible roles' (roleDefinitionId), but leaves justification and directoryScopeId unexplained, which is a significant gap.

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 explicitly defines the tool as a just-in-time PIM elevation action where the delegated caller self-activates one of their own eligible directory roles. It distinguishes itself from sibling tools by focusing on role activation rather than user/group/license management, and even provides an example (Authentication Administrator for Temporary Access Pass).

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 states clear prerequisites: requires a delegated token and fails if the caller is not eligible, which helps the agent know when to use it. It also implies the use case for elevating to a role needed for Temporary Access Pass. However, it does not explicitly contrast with alternative tools or say when not to use it.

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

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

The description adds a behavioral detail not present in annotations: 'Idempotent when the user is already a member.' This is valuable context beyond the readOnlyHint, destructiveHint, and idempotentHint flags. No contradiction with annotations is present.

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 two sentences long and front-loads the primary action. Every word earns its place, with no filler or redundant information.

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 two-parameter tool with no output schema, the description is adequate but minimal. It covers the core operation and one behavioral nuance, but does not mention return values, error conditions, or permissions. Given the simplicity, this is acceptable but leaves gaps that an agent might need to infer.

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 input schema has 0% description coverage, and the description does not explain the parameters userId and groupId beyond their names. The names provide some semantic hint, but the description fails to add any meaning such as formats, valid values, or relationships.

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 clearly states the action 'Add a user to a group' with a specific verb and resource. It distinguishes from sibling tools like remove_group_member and list_group_members by specifying the 'add' operation. The idempotency note further clarifies the purpose.

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 context for using this tool is implied by its name and description, but there is no explicit guidance on when to use it versus alternatives. No exclusions or alternative tool references are provided, but the purpose is clear enough that an agent could infer usage.

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

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

Annotations already indicate a non-read-only, non-destructive write operation. The description adds valuable behavioral context: it sets usageLocation before assigning the license and fails if the usageLocation is missing. This discloses a side effect and failure condition beyond what annotations provide, without contradiction.

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 sentence that front-loads the core action, then adds a concise behavioral note. Every word earns its place, with no filler or repetition.

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 4-parameter tool with no output schema, the description is adequate but leaves gaps. It covers the key behavior and failure mode but does not explain disabledPlans, the expected format for user/license, or return values. It is a viable minimum but not richly 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?

Schema description coverage is 0%, so the description should compensate. It only clarifies usageLocation ('Sets usageLocation first when provided'), while user and license are self-explanatory from the tool name. However, disabledPlans is left completely unexplained—an agent would not know what it means without additional context.

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 clearly states the tool's action: 'Assign a license to a user.' This is a specific verb+resource that distinguishes it from siblings like remove_license and set_usage_location. It also adds a unique behavioral note about usageLocation, further clarifying its purpose.

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 implies usage context by stating 'Sets usageLocation first when provided; fails clearly if the user has no usageLocation.' This suggests when to use the tool (to set usageLocation inline) and a prerequisite (user must have a usageLocation), but it does not explicitly name alternatives like set_usage_location or state when not to use it.

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

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

The description discloses several important behavioral traits beyond annotations: multi-use by default, regeneration until alphanumeric, lifetime limited by tenant policy, and return of the passcode for out-of-band delivery. These details are valuable and not presented in the annotations.

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 three sentences, front-loaded with purpose, followed by behavioral details and return value. Every sentence adds meaningful information without unnecessary fluff.

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?

The description covers essential context for a creation tool: purpose, key behaviors, return value, and a security caveat. It lacks explicit error conditions or prerequisites like admin role, but given the absence of an output schema and the richness of the description, it is fairly 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 description adds meaning to several parameters: 'multi-use by default' relates to isUsableOnce, 'regenerated until alphanumeric' relates to requireAlphanumeric, and 'lifetimeInMinutes bounded by policy' adds context. However, it does not explain maxAttempts, startDateTime, or user. With zero schema description coverage, this is partial compensation.

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 clearly states the action ('Create'), the resource ('Temporary Access Pass'), and the specific use case ('passwordless first sign-in / MFA setup'). It also differentiates from related tools like delete_temporary_access_pass by emphasizing creation and default multi-use behavior.

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 clear context for when to use the tool: during initial sign-in or MFA setup. It does not explicitly mention alternatives or exclusions, but the scenario is specific enough to imply appropriate usage. The security note to deliver the passcode out-of-band adds additional usage context.

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

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

The description adds meaningful context beyond the annotations: it discloses that the password is generated, returns it, and instructs the agent to store it securely and share out-of-band. This complements the readOnlyHint=false and openWorldHint=true annotations by clarifying the security sensitivity of the generated secret. There is no contradiction with annotations.

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 one short sentence plus an imperative instruction, both front-loaded and free of fluff. It states the primary action first, then the critical security note, achieving high information density with zero wasted words.

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?

Given the tool's complexity (8 parameters, 2 required, no output schema) and the surrounding ecosystem (siblings like assign_license, set_usage_location), the description is too sparse. It does not hint at additional steps (e.g., assigning licenses) or potential failure conditions (e.g., duplicate UPN). The only useful context is the return of the temporary password, but that alone is insufficient for a create operation in a large tenant.

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?

Description does not mention any input parameters or their meaning. With schema description coverage at 0%, the description must compensate, but it only vaguely refers to 'generated temporary password' without clarifying that the password field is optional or how displayName/userPrincipalName are used. The agent must rely entirely on the schema alone, which is insufficient for ambiguous fields like checkExisting or usageLocation.

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 clearly states the tool's function: creating a Microsoft 365 user. It also specifies that a temporary password is generated and returned, which distinguishes it from other user-related tools like update_user or list_users. The action verb 'Create' and resource 'user' are explicit and unambiguous.

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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as licensing or usage location, nor does it exclude scenarios where another tool (e.g., create_temporary_access_pass) would be more appropriate. The only advice given is about handling the password, which pertains to post-creation behavior rather than tool selection.

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

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

Annotations already warn that the tool is destructive and not read-only. The description adds essential behavior: with methodId it deletes that specific pass, otherwise every TAP on the user. This conditional behavior goes beyond the annotations, giving agents clear expectations.

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, well-structured sentence that front-loads the primary action and uses a semicolon to add the conditional detail. Every word contributes to understanding, with no redundancy or filler.

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 destructive, idempotent delete operation, the description covers all key decision points (whether methodId is provided) and does not need to explain return values since there is no output schema. Combined with annotations, it provides complete contextual guidance.

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?

With 0% schema description coverage, the description compensates by explaining methodId's role and the default behavior when it is absent. It does not specify the format for user, but 'a user's' and sibling tool context imply a standard user identifier, making it sufficient.

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 opens with 'Delete a user's Temporary Access Pass,' clearly stating the action (delete), resource (Temporary Access Pass), and scope (a user's). This distinguishes it from the sibling create_temporary_access_pass and other user management tools, and the conditional methodId clause further refines the tool's purpose.

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 implies when to use this tool—whenever a user's Temporary Access Pass needs deletion—and clarifies the two modes via methodId presence. It does not explicitly mention alternatives or exclusions, but the action is inherently differentiated from create and activate operations.

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

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

Annotations already cover safety (read-only, idempotent, non-destructive). The description adds no further behavioral context such as error handling, authentication, or return format, providing no value beyond the annotation layer.

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?

Single sentence with no fluff, front-loaded verb and resource. Every word earns its place.

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?

With 2 parameters and no output schema, the description omits the optional select parameter and any return/error details, making it incomplete for full usage.

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. The description clarifies that groupId is the object ID but says nothing about the select parameter, leaving it undocumented.

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 the verb 'fetch' with the resource 'group' and specifies 'by object id', clearly differentiating from siblings like list_groups (lists) and list_group_members (members). It is specific and unambiguous.

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?

It indicates the tool retrieves a single group by object ID, giving clear context for when to use it. However, it does not explicitly mention alternatives or exclusions, so it stops short of a full guideline.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, idempotent read. The description adds the lookup key context (object id or userPrincipalName) but no additional behavioral traits such as return format or error behavior. With strong annotations, the bar is lower, and the description meets it without adding extra value.

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 sentence that is concise and directly conveys the essential information. No wasted words or repetition of the title.

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?

The tool is simple, with good annotations and no output schema. The description tells how to identify the user but does not mention what fields are returned or that 'select' can be used to choose specific properties. For a basic fetch operation, this is adequate but not fully 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 provides no descriptions for parameters (0% coverage), so the description must compensate. It clarifies that 'user' can be an object id or userPrincipalName, adding meaning to the first parameter. However, it does not explain the 'select' parameter (e.g., that it limits returned fields), leaving a gap for one of the two parameters.

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 clearly states 'Fetch one user by object id or userPrincipalName,' using a specific verb and resource. It distinguishes this tool from siblings like list_users (which fetches multiple users) and get_group (which fetches a group). The scope is unambiguous.

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 clear context for when to use the tool: to retrieve a single user based on a specific identifier. It does not explicitly mention when not to use it or name alternatives, but the distinction from list_users is implied. This is sufficient for a straightforward read operation.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds the nuance 'currently assigned,' which implies the result reflects the current state. However, it does not disclose pagination, sorting, or any other behavioral details beyond what annotations already provide.

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 sentence, front-loaded with the verb and object, with no wasted words. It is concise and structurally efficient.

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?

Given the tool's simplicity—one parameter, good annotations, no output schema—the description adequately communicates the core purpose and what the result will be (a list of licenses). Minor gaps include the lack of parameter format and no mention of response structure, but these do not undermine the overall completeness for this straightforward read-only operation.

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?

Schema description coverage is 0%—the parameter 'user' has only a type and minLength. The description does not add meaningful semantics: it says 'a user' but does not specify whether this is an ID, email, or UPN, nor any format constraints. The parameter name itself is self-explanatory, so the description adds minimal value.

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 'List the licenses currently assigned to a user' uses a specific verb ('List') and resource ('licenses') with clear scope ('to a user'). It distinguishes itself from sibling tools like assign_license and remove_license, and from list_subscribed_skus which lists available SKUs rather than user-assigned licenses.

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 intended use is implied: to fetch a user's current licenses. However, no explicit guidance is given on when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. It is not misleading, but it lacks the explicitness of a higher score.

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

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

The description adds no behavioral context beyond the annotations. Annotations already declare readOnlyHint=true and destructiveHint=false, but the description does not mention pagination, ordering, error behavior, or other nuances. No contradiction with annotations.

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 concise sentence with no fluff. However, it is under-specified, lacking any detail beyond the basic action.

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 tool with 2 parameters and no output schema, the description is too sparse. It does not explain the meaning of 'top', what the response contains, or any usage distinctions. The annotations provide safety information, but the description itself is incomplete.

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, and the description does not explain the parameters 'groupId' or 'top'. 'top' is particularly ambiguous as it could mean a limit or count, but no clarification is provided.

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 the specific verb 'List' with the resource 'members of a group', clearly stating the action. It distinguishes itself from sibling tools like list_groups (which lists all groups) and add_group_member (which adds members).

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 information about when to use this tool versus alternatives, such as get_group or list_users. There are no conditions, prerequisites, or exclusions mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond the schema—it does not mention pagination, default result sizes, or response format. It only restates the parameter names.

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 sentence, front-loaded with the action 'List groups', and contains no filler or redundant content. While brief, it is efficiently structured.

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?

There is no output schema, so the description should clarify what the tool returns (e.g., a list of group objects). It also lacks usage context, parameter semantics, and any mention of limitations or defaults. Given the tool's relative simplicity, the description is under-specified for an agent to invoke it confidently.

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 no descriptions for parameters, and the description only lists their names without explaining their meaning or syntax. For example, it does not clarify that 'filter' uses OData filtering syntax or that 'select' limits returned properties. With 0% schema description coverage, this falls short of compensating for the lack of detail.

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 clearly identifies the action ('List groups') and the resource (Microsoft 365 Groups), and it mentions the optional OData parameters ($top, $filter, $select, $orderby). It does not explicitly differentiate from sibling tools like get_group or list_group_members, but the resource is unambiguous.

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?

There is no guidance on when to use this tool versus alternatives. It does not mention scenarios such as 'use get_group for a single group' or 'use list_group_members for group members', leaving the selection to the agent's inference from the tool name.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint false, so the description only needs to add context. It adds tenant scope and the seat availability purpose but does not disclose return format or pagination. This is consistent but not highly enriching.

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?

A single, front-loaded sentence with no filler. It immediately states the action and purpose, making it easy for an agent to parse and understand.

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 zero-parameter, read-only tool with rich annotations, the description is complete enough. It states what is listed and why, and the sibling context clarifies its role. No output schema exists, but the description's simplicity minimizes the need for more detail.

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 tool has zero parameters and 100% schema coverage, so the description has no burden to explain parameters. According to the baseline for 0 params, this scores a 4. The description does not need to add any parameter guidance.

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 clearly states 'List tenant subscribed SKUs' with a specific verb and resource. Adding 'for license lookup and seat availability' clarifies the purpose and distinguishes it from sibling tools like get_user_license_details or assign_license.

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 phrase 'for license lookup and seat availability' provides clear context on when to use this tool, indicating tenant-level license inventory. It does not explicitly mention alternatives or exclusions, but the use case is well implied given the sibling tools.

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

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

Annotations already disclose readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds only that query parameters are optional (already visible in the schema) but does not mention pagination, default response size, or rate limits.

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?

A single, punchy sentence that front-loads the primary action and lists the parameters succinctly. Every word earns its place, though it sacrifices depth for brevity.

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?

With no output schema and zero parameter explanations, the description leaves the agent uninformed about pagination, default return fields, or OData syntax. For a listing tool with 4 parameters, this is insufficient for confident invocation.

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?

Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It merely lists the parameter names without describing what $top, $filter, $select, or $orderby do semantically, adding minimal value over the schema.

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 clearly states the tool's action ('List') and resource ('users'), distinct from siblings like get_user. It is specific and unambiguous, with the title reinforcing the Microsoft 365 scope.

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 implies usage for enumerating users but does not explicitly state when to use it versus alternatives like get_user or list_groups. No exclusion criteria or alternative tool references are provided.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds a specific edge-case behavior: 'Idempotent when the user is not a member.' This goes beyond the generic idempotentHint annotation and provides valuable context about how the tool behaves under a specific condition.

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 two short sentences with no fluff or redundant information. It states the core action and one key behavioral detail, making it highly concise and well-structured.

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?

Given the tool's simplicity, the description combined with annotations covers the essential behavior. It doesn't mention return values or potential errors, but there is no output schema, and the annotations provide safety guidance (destructiveHint, idempotentHint). Overall, it is sufficiently complete for this mutation tool.

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 two parameters (groupId, userId) with no descriptions (0% coverage). The description compensates by framing the action in terms of 'user' and 'group,' which maps to the parameters, but it doesn't provide additional constraints, formats, or context. The parameter names are self-explanatory, so the description adds minimal value beyond them.

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 clearly states the action: 'Remove a user from a group.' This is a specific verb + resource, and it naturally distinguishes itself from siblings like add_group_member and remove_license. It also includes a useful behavioral note about idempotency.

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 clear context for when to use the tool (removing a user from a group). It doesn't explicitly mention alternatives or exclusions, but the context is unambiguous and self-evident. For a simple operation, this is adequate guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond restating the action—no mention of permanence, side effects, or impacts on user access. Minimal additional transparency beyond annotations.

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 concise sentence, front-loaded with the action. It avoids redundancy and is easy to parse. However, it may be too terse, sacrificing necessary detail for brevity, but as a purpose statement it is appropriately sized.

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?

With two required parameters and no output schema, the description must provide enough context for correct invocation. It fails to specify parameter formats, prerequisites, or the operation's effect. The annotations cover safety but not usage completeness, leaving the tool under-specified for an agent.

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?

Schema description coverage is 0%, and the description does not explain the 'user' or 'license' parameters beyond their names. It provides no hints about accepted formats (e.g., UPN vs object ID, SKU ID vs product name). With no enums or schema descriptions, the agent must guess, and the description offers little help.

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 specific verb ('remove') and clearly identifies the resource and target ('license from a user'). It distinguishes from sibling tools like assign_license and remove_group_member. The action is unambiguous and matches the tool's title.

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 gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., checking current licenses with get_user_license_details), nor does it suggest scenarios where removal is appropriate. This is a bare statement with no usage context.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false) and not idempotent, but the description adds no behavioral context beyond that. It does not mention whether the manager is replaced, if validation occurs, or what side effects might happen (openWorldHint=true). The description is purely declarative without useful behavioral detail.

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 one brief sentence that gets straight to the point ('Set a user's manager') followed by a necessary input clarification. It is front-loaded and contains no superfluous words, making it highly concise and well-structured.

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 2-parameter setter with no output schema, the description is adequate but not complete. It covers the action and manager format, but omits details about the 'user' parameter, expected return values, or any preconditions. Given the tool's simplicity, this is acceptable but leaves some key questions unanswered.

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 input schema provides no descriptions for either parameter (0% coverage). The description explains that the 'manager' parameter accepts an object id or userPrincipalName, which adds meaning beyond the schema. However, the 'user' parameter is not clarified at all; it is only implied to be the user whose manager is set, with no format specified. This partial compensation leaves a gap.

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 clearly states the action ('Set a user's manager') with a specific resource (user) and distinguishes it from sibling tools like set_usage_location or assign_license. It also specifies the input format for the manager (object id or userPrincipalName), leaving no ambiguity about the tool's purpose.

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 gives no guidance on when to use this tool versus alternatives (e.g., update_user) and does not mention any prerequisites or exclusions. It is implied that this tool is for setting the manager field, but there is no explicit context or comparison with sibling tools.

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

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

The description adds little beyond the annotations. It does not disclose potential side effects, permission requirements, or consequences of setting the location. Annotations already indicate a non-read-only, non-destructive mutation, but the description does not elaborate on the openWorldHint or any subtle behaviors.

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?

One short sentence that is immediately clear and front-loaded. No wasted words.

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?

The tool is simple, but the description omits information about return values, parameter meanings, and behavioral nuances. The prerequisite note is helpful, but overall the description leaves the agent with unanswered questions, especially given no output schema.

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?

Schema coverage is 0% and the description does not explain the semantics of 'user' or 'usageLocation' (e.g., that usageLocation is a two-letter country code). The parameter names are self-explanatory to a degree, but the description fails to compensate for the lack of schema descriptions.

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 clearly states the action ('Set a user usageLocation') and identifies the resource, with a helpful prerequisite note ('required before license assignment'). This distinguishes it from sibling tools like assign_license.

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 phrase 'required before license assignment' provides clear context for when to use this tool (prior to assigning licenses). However, it does not explicitly mention alternatives or exclusion scenarios, stopping short of full when/not guidance.

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

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

Annotations establish that the tool is not read-only and not destructive. The description adds behavioral transparency beyond annotations by specifying the PATCH method and emphasizing that only provided fields are changed. It also gives concrete, real-world examples of accountEnabled usage. This aligns with annotations and adds useful context about side effects and scope of changes.

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 two sentences long, front-loaded with the primary purpose ('Update attributes on an existing user (PATCH)'), followed by a specific, high-value use case and a behavioral note. Every word contributes, with no filler or redundancy.

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?

Despite having 19 parameters and no output schema, the description adequately covers the tool's core purpose and behavior: it updates existing users, uses PATCH semantics, and specifically highlights accountEnabled for account lifecycle management. The 'existing user' qualifier sets the context. While individual attributes are not enumerated, the generic 'Update attributes' phrase signals that any of the schema properties may be set, making the description sufficient for overall tool selection.

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?

Schema description coverage is 0%, so the description must compensate for explaining parameter meanings. It only explains accountEnabled (to enable/disable accounts), while the other 18 parameters (e.g., city, state, otherMails) receive no additional semantic context beyond their names. The schema already shows property names and types, but the description fails to clarify how these attributes are used or their business meaning, leaving most parameters without added value.

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 clearly states the tool's function: 'Update attributes on an existing user (PATCH)'. It specifies the verb (update), the resource (existing user), and the HTTP method, distinguishing it from create_user and specific setter tools like set_usage_location. The accountEnabled example further clarifies a key use case.

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 clear context for when to use the tool: updating existing users, enabling/disabling accounts via accountEnabled (e.g., activating pre-created hires or disabling leavers). It also notes that only provided fields are changed, setting expectations for partial updates. However, it does not explicitly state when not to use it or name alternative tools for specific operations.

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