Get an Entra application

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

Annotations already cover read-only, idempotent, and non-destructive behavior, lowering the burden. The description adds useful context beyond that: it specifies the output is 'published scope metadata' and that the tool applies to 'Microsoft first-party application' IDs, which are behavioral constraints not present in the annotations. It doesn't mention auth or rate limits, but those are less critical given the annotation profile.

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, front-loaded sentence that conveys the main action, scope, and optional parameter without any fluff or repetition. Every word contributes to understanding the 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 tool with 3 parameters, no output schema, and annotations covering safety, the description provides the essential purpose, the exact-match behavior, and the optional resource filter. However, it omits any mention of the include_redirect_uris parameter, which lacks a schema description, leaving a small but meaningful gap for an agent deciding whether to set it.

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 67% (app_id and resource have descriptions, include_redirect_uris does not). The description adds meaning to app_id (exact, first-party) and resource (optional narrowing), but it does not compensate for include_redirect_uris, which remains undocumented in both schema and description. This is adequate but partial, so the baseline of 3 is appropriate.

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 states a specific verb ('Get'), resource ('published scope metadata'), and target ('one exact Microsoft first-party application ID'), and notes an optional narrowing ('optionally narrowed to a resource'). This clearly distinguishes it from siblings like search_entra_applications (search vs exact lookup) and get_entrascopes_data_status (status vs metadata).

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 makes its usage context explicit by specifying it is for 'one exact Microsoft first-party application ID', which implies this is for precise lookups when the ID is known. However, it does not explicitly mention alternative tools or when not to use it, stopping short of a full when/when-not comparison.

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