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

Annotations already convey the safety profile (readOnlyHint=false, idempotentHint=false), and the description adds genuinely useful behavioral context beyond them: the confirm=true approval gate, the side effect that attendees get invitations, and the optional Teams meeting behavior. It doesn't contradict any annotation — 'WRITE operation' aligns with readOnlyHint=false. It stops short of disclosing duplicate-event behavior on repeated calls or undo/reversibility, but the core side effects an agent must know before invoking are 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?

Two dense sentences with no filler. The core purpose is front-loaded ('CREATE a calendar event'), followed by the key option and side effect, then the critical safety requirement. Every clause earns its place, and the WRITE/confirm warning is positioned last as a gate the agent must respect before executing.

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 10-parameter write operation with side effects and no output schema, the description covers the essentials: action, scope, options, invitation side effect, and the approval gate. The main gaps are the absence of return-value/response context (no output schema exists to fill that) and no guidance about what happens with non-default calendars or how to later modify the created event. These are secondary to the operational behavior, which is well covered.

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 100%, so the schema fully documents all 10 parameters including the confirm safety gate and timeZone default. The description reinforces the confirm requirement and references attendees ('attendees get invitations') and isOnlineMeeting ('optionally as a Teams online meeting'), but adds no semantic detail beyond what the schema already provides. Per the rubric, a 3 is the correct baseline when the schema carries the parameter-documentation burden.

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 (CREATE), a specific resource (calendar event), and a precise scope (signed-in user's default calendar). The verb alone distinguishes it from the sibling read tools (get-calendar-view, list-calendar-events), the update tool (update-calendar-event), and the response tool (respond-to-calendar-event), none of which create events. The Teams-online-meeting option and invitation side effect further pin down exactly what this operation does.

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 usage is clear by implication: when the user asks to create a calendar event, this is the tool. However, the description provides no explicit when-to-use versus alternatives guidance, no exclusions, and no mention that modifying an existing event should go to update-calendar-event or that finding a free slot should use find-meeting-times. The safety-gate note ('requires confirm=true') is procedural, not usage-routing 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 indicate mutation (readOnlyHint=false, idempotentHint=false), but the description adds context beyond them: it clarifies the draft is stored in the Drafts folder and that no sending occurs. It also notes the approval requirement for the follow-up send action. 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?

Two sentences, no filler. The most important behavioral fact ('Does NOT send anything') is front-loaded, and the alternative is named in the second sentence. Every part 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?

Given the schema covers params well and annotations exist, the description is largely complete for selection and invocation. It could mention what the tool returns (e.g., draft ID) since there is no output schema, but that gap is minor for a create-draft action.

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 86%, so the schema already documents most parameters. The description adds no parameter-specific meaning, but that's acceptable since the schema carries the burden. It does not need to compensate for gaps, so the baseline 3 applies.

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?

Description states a specific verb and resource: 'Create a DRAFT email in the signed-in user's Drafts folder.' It clearly differentiates from the sibling send-draft-email by emphasizing it does NOT send anything. This is a precise, distinguishable 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?

Explicitly tells the agent when not to use this tool ('Does NOT send anything') and names the alternative ('use send-draft-email') with a condition ('with explicit user approval'). This is direct, actionable routing 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?

The description adds a critical behavioral guarantee beyond the annotations: a draft is created but no email is transmitted. The annotations already indicate this is a write operation, but the explicit 'Does NOT send' clarifies the main side-effect boundary an agent needs to know.

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?

Two short sentences with no wasted words. The action is front-loaded, and the crucial caveat that it does not send immediately follows.

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 draft-creation tool, the description plus schema cover the required inputs and the key outcome. It could mention how to later send the draft or what the response contains, but with no output schema those are not essential for correct 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?

The schema already provides descriptions for 88% of parameters, including bodyType defaults and required fields. The description itself adds no parameter-level detail, so it does not need to compensate for schema coverage.

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 ('Create'), a specific resource ('DRAFT in a shared mailbox'), and explicitly distinguishes the action from sending ('Does NOT send'). This clearly separates it from sibling tools like send-shared-mailbox-mail and create-draft-email.

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 the right use case—composing a draft in a shared mailbox—but does not explicitly name alternatives or state when not to use it. An agent must infer that sending tools and personal-mailbox draft tools are different based on the name and the 'Does NOT send' caveat.

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 mark the operation as read-only, idempotent, and non-destructive, and the description adds valuable runtime behavior: specific file types are converted to text, other binaries are returned as base64, and the result is size-limited by MAX_DOWNLOAD_BYTES. This meaningfully goes beyond the annotation hints, though the exact behavior when the size limit is exceeded is not disclosed.

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 short sentences with the core action front-loaded, followed by the conversion behavior and the size limit. Every clause adds distinct information with no redundant wording, making it easy for an agent to scan.

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, the description reasonably explains the main return forms (text vs base64) and the size limit, which is essential for deciding how to handle the result. It leaves gaps around the exact response envelope, error conditions, and what happens when MAX_DOWNLOAD_BYTES is exceeded. These are material omissions for a tool that returns arbitrary file content.

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 describes all three parameters, so the baseline is 3. The description adds meaningful context for the optional fileName parameter by mentioning text extraction, which explains why the filename helps pick the right extractor. It does not, however, add real semantic value for driveId or itemId beyond the schema's generic 'Value for driveId/itemId' text.

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 action ('Download a file's content from SharePoint') and distinguishes the tool from nearby siblings like get-drive-item by specifying that the output is either converted text or base64-encoded binary. However, it does not explicitly differentiate from download-my-drive-item, leaving some ambiguity about which drive context applies.

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?

No explicit guidance is given for when to use this tool versus the closely related siblings download-my-drive-item, get-drive-item, or get-my-drive-item-download-url. The phrase 'from SharePoint' implies a SharePoint drive as opposed to a personal OneDrive, but the description does not state that contrast or mention any alternative 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?

Description adds meaningful details beyond readOnly/idempotent annotations: Office/PDF/TXT/CSV become text, other binaries are base64, and there is a size limit. This helps the agent predict return shape and failure mode.

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?

Two sentences with no fluff; action first, then format and limit behavior.

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?

Covers the main thing no output schema would tell the agent: representation of returned content and size bound. It doesn't state the actual MAX_DOWNLOAD_BYTES value or behavior over the limit, but for a two-parameter downloader this is near-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 already documents both parameters, so baseline is 3. The description reinforces fileName's role in extractor selection but adds little beyond what schema states, and itemId remains generic.

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?

States the action (download), resource (OneDrive file content), and gives concrete output-format behavior. It separates itself from metadata-oriented siblings like get-my-drive-item, although it does not explicitly differentiate from download-drive-item or get-my-drive-item-download-url.

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?

No explicit when-to-use or alternative-routing guidance. The agent must infer from the name/title that this is the content-fetching counterpart to get-my-drive-item-download-url and download-drive-item.

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 description does not need to repeat that this is safe. It adds useful context about the computation being based on free/busy data and working hours, but it does not disclose edge behavior such as returning no suggestions or how candidate limits apply.

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 names the action, scope, and data source with no filler or redundancy. Every word contributes useful meaning.

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 moderately complex read-only tool with all parameters documented in the schema and no nested objects, the description gives enough about what the tool computes and for whom. It does not spell out the return shape because there is no output schema, but the result ('time slots') is readily inferable from the description and title.

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 100%, so the schema itself fully documents all six parameters. The description adds no parameter-specific meaning beyond reiterating the concept of attendees and meeting times, so the baseline score 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 ('Suggest'), a concrete resource (meeting time slots), and the data basis (free/busy data and working hours). It is clearly distinct from calendar-reading tools, though it does not explicitly differentiate itself from the sibling get-people-availability, which could plausibly be mistaken for an alternative.

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?

Usage is implied: the agent should use this when it needs to propose workable meeting slots for a signed-in user and attendees. However, there is no explicit when-to-use, when-not-to-use, or comparison to alternatives such as get-people-availability for raw availability retrieval.

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 carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), lowering the bar for additional disclosure. The description adds genuine behavioral context beyond annotations by explaining the resolution semantics and the tool's role as the connection point between calendar events and meeting artifacts, so an agent can predict what the result enables.

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?

Two sentences with zero waste: the first states the core action and its input chain, the second explains the downstream payoff. The resolving action is front-loaded ahead of the workflow context, and every clause 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?

For a lookup tool with a single required parameter, a fully documented schema, and annotations covering safety and idempotency, the description addresses purpose, trigger condition, and downstream usage. The only gaps are the lack of an output schema and no stated behavior for the not-found case, which are minor given the explicit pointer toward transcript/recording/attendance siblings.

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 100% and each parameter (joinWebUrl, cursor, maxItems) already carries rich schema-level documentation, including pagination semantics. The description only reinforces that joinWebUrl originates from event.onlineMeeting.joinUrl rather than adding new parameter-level detail, so the high-coverage baseline of 3 applies.

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-resource pair — 'Resolve an onlineMeeting from a Teams join URL' — and reinforces it with a precise pipeline notation (calendar event -> onlineMeeting.joinUrl -> this tool). This distinguishes it from siblings like get-online-meeting or list-calendar-events by establishing the exact input and where that input comes from.

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 conveys a clear trigger scenario: when an agent has a calendar event's onlineMeeting.joinUrl and needs to reach transcripts/recordings/attendance, this is the required bridge tool. It does not, however, name explicit exclusions or contrast alternatives such as get-online-meeting for cases where a meeting ID is already available.

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), non-idempotent, and not destructive. The description adds 'Requires confirm=true,' but this detail is already present in the confirm parameter schema, so it adds little 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 two short clauses with no filler. The core action and the critical confirm requirement are both front-loaded.

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, combined with the fully annotated schema, is enough to invoke the tool correctly. It could be improved by explicitly naming the shared-mailbox alternative or noting that forwarding sends an email, but these are not blocking gaps.

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 100%, so the baseline is 3. The description's mention of confirm=true reinforces a key requirement, but it does not add semantic meaning beyond what the parameter descriptions already provide.

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 and resource: 'Forward a message' scoped to 'as the signed-in user.' This clearly distinguishes it from the sibling forward-shared-mailbox-mail, which targets shared mailbox contexts.

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 'as the signed-in user' qualifier provides clear context for when this tool applies, implicitly excluding shared-mailbox forwarding. However, it does not explicitly name alternatives or state when not to use this tool.

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 this is a non-read-only, non-idempotent write operation. The description adds the key behavioral requirement that 'confirm=true' is mandatory, reinforcing the safety gate. It does not disclose more about side effects, such as sending emails to recipients or confirmation flow details, but it is not misleading and does not contradict 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 extremely concise: one action sentence and one mandatory confirmation requirement. It is front-loaded and contains no filler; every word contributes to understanding the tool's core purpose and critical safety gate.

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 a straightforward write operation with a complete schema and clear annotations. The description conveys the essential action and confirmation requirement, but it omits any guidance on when to choose this over the normal forward-mail sibling and does not mention expected outcomes or return behavior. It is minimally viable but not rich in context.

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 100%, so all five parameters already have descriptive text. The description adds no further parameter-level meaning. Baseline 3 is appropriate because the schema carries the semantic weight.

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 action and resource: 'Forward a shared-mailbox message.' This clearly distinguishes it from sibling tools like forward-mail and reply-shared-mailbox-mail by the shared-mailbox scope. The 'Requires confirm=true' addition reinforces that this is an executable write action.

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 does not explicitly state when to use this tool versus alternatives such as forward-mail or reply-shared-mailbox-mail. The shared-mailbox wording implies the target domain, but no exclusions, conditions, or alternative routing 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds no behavioral context beyond what annotations and schema provide, such as return shape, not-found behavior, or required scopes.

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 clear sentence with no filler. It front-loads the action and object, making the tool's purpose immediately scannable.

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, one-parameter, read-only getter annotated as idempotent and non-destructive, this description is sufficient. No output schema exists, but the expected behavior—return a calendar by id—is fully implied by the description and name.

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 100%, so the single required parameter calendarId is documented. The description does not enrich the parameter beyond the schema, but with full schema coverage, 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'), a specific resource ('a single calendar'), and a clear selection mechanism ('by id'). This distinguishes it from list-calendars and get-calendar-view, making its purpose immediately clear.

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 when you already have a calendarId and need a single calendar, but it does not explicitly mention when to use it over list-calendars or how to obtain the id. The guidance is adequate but leaves the relationship to sibling tools to inference.

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 the tool read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful context about what fields are returned, but it does not disclose potential behaviors such as not-found handling, authentication needs, or how the optional $select parameter affects the response.

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 tool's purpose and key return fields with no filler. Every word contributes meaningful 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 read operation with one required parameter, full schema coverage, and strong annotations, the description is largely complete. It communicates the scope and the important content of the response, though it could mention error behavior or response shape more explicitly since no output schema is provided.

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 100%, and both eventId and select already have clear schema descriptions. The description does not add significant parameter-level meaning beyond the schema, so the baseline score 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 and resource: get a single event. It also enumerates the distinguishing content fields (body/description, attendees, online meeting info, recurrence), which clearly separates it from sibling list tools like list-calendar-events and get-calendar-view.

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?

Usage is implied: an agent should call this when it needs one specific event's full details. However, there is no explicit guidance contrasting it with list-calendar-events or get-calendar-view, and no when-to-use or when-not-to-use instructions 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 readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context: it expands recurring occurrences, requires a time range, and enumerates returned fields including onlineMeeting join URL and recurrence. 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?

Two tight sentences with no filler. The core purpose is front-loaded, the requirement is stated, and the return payload summary 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?

There is no output schema, so the description carries the burden of describing return values, which it does by listing organizer, participants, start/end, location, join URL, and recurrence. Pagination and filtering are left to the schema, which fully documents them, so nothing critical is missing.

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 100%, so the baseline is 3. The description adds a meaningful constraint not captured by the schema's optional fields: 'Requires timeRange or from/to.' It also indicates which fields are important in the response, aiding parameter selection.

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?

Description states a specific verb+resource: 'list all calendar events' within a time range, and positions itself as the 'PRIMARY meeting-lookup tool.' It also calls out recurring occurrences, which distinguishes it from event-specific siblings like get-calendar-event or list-calendar-events.

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?

Clear context is given: use as the primary meeting lookup tool and provide timeRange or from/to. It does not explicitly contrast with list-calendar-events or get-calendar-event, but the 'PRIMARY' framing and requirement statement provide adequate routing 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 readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the read-only nature is fully covered. The description adds no behavioral context beyond the resource being retrieved, but it also does not contradict 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 a single, straightforward sentence with no unnecessary words. It is appropriately sized for a simple get-by-ID operation.

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 get operation with three required string parameters and rich annotations, the description is mostly sufficient. It does not describe the returned message payload since there is no output schema, but the tool name and siblings make the expected result reasonably clear.

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 100% description coverage for parameters, but each description is the tautological 'Value for teamId/channelId/messageId', providing no real semantics. The tool description adds minimal meaning by implying these identify a channel message, but it does not clarify relationships or message ID format.

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 'Get a single channel message' states a specific verb and resource, clearly identifying that this tool retrieves one channel message. It is distinguishable from siblings like list-channel-messages or get-chat-message by the 'channel message' resource, though it does not explicitly contrast with any sibling.

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 such as list-channel-messages, get-chat-message, or list-channel-message-replies. The word 'single' weakly implies retrieving one item rather than listing, but no usage context or alternative routing is given.

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 that this is a read-only, idempotent, non-destructive operation, so the safety profile is clear. The description adds that the response includes chat members, which is non-obvious and valuable given there is no output schema.

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 with no filler. Every word adds meaning: get is the action, single chat is the resource, and including its members clarifies the response scope.

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 one-parameter read-only getter, the description plus annotations cover the core calling requirements. The main missing item is more explicit guidance about choosing this over list-chats, but the description adequately conveys what the tool does and what the response includes.

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 already documents chatId with a description and minLength, and schema description coverage is 100%. The tool description adds no additional semantic detail about the parameter, so the baseline score of 3 applies.

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'), a specific resource ('a single chat'), and the scope ('including its members'). This clearly distinguishes it from list-chats, which returns multiple chats, and get-chat-message, which targets a message within a chat.

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 'single chat' implies this tool should be used when the agent already has a chatId and needs one chat, rather than listing chats. However, it does not explicitly name alternatives or state when not to use this tool, leaving the routing decision mostly to inference.

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 annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds no additional behavioral context beyond the word 'Get', such as return format, error behavior, or relationship to other message operations.

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 with no filler or repetition. Every word earns its place, and it is appropriately sized for a simple getter.

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 read-only getter with two required parameters and no output schema, the description is minimally adequate but incomplete. It provides no return-value expectations, no clarification of how chatId and messageId relate, and no mention of the sibling list operation, which would help an agent use 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?

Schema description coverage is 100%, so the baseline is 3 even though the description itself adds no parameter detail. The schema's parameter descriptions ('Value for chatId', 'Value for messageId') are weak, but the description does not make them worse or introduce confusion.

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 and resource ('Get a single chat message') and the word 'single' distinguishes it from list-oriented siblings like list-chat-messages. However, it does not explicitly differentiate the chat resource from channel messages, leaving some ambiguity among get-chat-message and get-channel-message.

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. The description does not mention list-chat-messages for browsing or get-channel-message for channel contexts, nor does it state any prerequisites or exclusions.

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 this as a safe, read-only, idempotent operation, so the description carries little additional burden. It adds a small clarifying detail by calling drive a 'document library', but no further behavioral traits such as authorization requirements, scope limitations, or response characteristics are disclosed.

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 focused sentence with no filler or redundancy. It front-loads the action and resource, and the parenthetical clarification is concise and useful.

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 low complexity, single required parameter with full schema coverage, and annotations that establish the safe read-only nature, the description is complete enough for an agent to correctly select and invoke this tool. No output schema exists, so return-value explanation is not expected here.

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 100% for the single driveId parameter, so the schema already documents it. The description does not add any semantic detail beyond restating that the operation is by id, which is appropriate for the high coverage baseline.

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 'Get a drive (document library) by id' uses a specific verb ('Get') and a specific resource ('drive'), and clarifies the domain term with 'document library'. The 'by id' qualifier distinguishes it from related tools like get-my-drive, which retrieves the current user's drive without an id.

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 does not state when to use this tool versus alternatives. It implies usage when a driveId is available, but it does not mention get-my-drive, list-site-drives, or other sibling tools, nor does it explain why a user would prefer this tool over them.

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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context by specifying that file metadata includes the @microsoft.graph.downloadUrl, while folder metadata does not. This goes beyond the structured annotations without contradicting them.

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 focused sentence with no filler. It front-loads the core purpose ('Get file/folder metadata') and immediately provides the most useful output-related nuance (downloadUrl for files).

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 get-by-ID tool with strong read-only annotations, the description is minimally viable. However, there is no output schema, and the description does not explain what metadata fields are included or how this tool relates to drive-specific siblings, leaving some contextual ambiguity.

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 100%, with driveId and itemId both documented, so the schema already carries the parameter meaning. The tool description adds no additional parameter-level context, which aligns with the baseline score of 3.

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 a specific action and resource: 'Get file/folder metadata.' It also adds a distinguishing detail by mentioning the @microsoft.graph.downloadUrl for files. However, it does not explicitly contrast itself with siblings like get-my-drive-item or download-drive-item, so differentiation is mostly implicit.

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 explicit guidance on when to use this tool versus alternatives such as download-drive-item, get-my-drive-item, or list-drive-* tools. The word 'metadata' implies it is for metadata rather than content, but no direct when-to-use or when-not-to-use guidance is 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 readOnly, idempotent, and non-destructive behavior, so the description adds useful context beyond them: the content is raw Fluid/JSON-like text and filename helps with text decoding. This is meaningful behavioral detail for an agent deciding whether and how to invoke the tool.

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?

Two sentences carry the full meaning with no redundancy. The most important selection information (what and how) is front-loaded, and the content format note is placed at the end without bloating the description.

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 download tool with strong annotations, the description covers the essential agent needs: what is returned, how to identify the target, and where the identifiers come from. No output schema exists, but the content-format hint compensates for that gap.

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 already describes all parameters, so the baseline is 3. The description adds valuable semantic provenance by explaining that driveId and itemId come from a search-loop-components hit's resource.parentReference, which is beyond the schema's simple 'Value for driveId' phrasing.

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 ('Download'), a specific resource ('Loop component's raw content'), and the exact identifiers needed, while distinguishing this from generic drive downloads by noting the Fluid/JSON-like text format and its origin in search-loop-components. It clearly separates this tool from sibling tools like download-drive-item or get-drive-item.

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 gives clear context for when to use this tool: after search-loop-components, using driveId and itemId from resource.parentReference. It does not explicitly name alternatives or state when not to use it, but the source-specific guidance is strong enough to route an agent correctly.

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 mark the tool as read-only, idempotent, and non-destructive, lowering the bar. The description adds genuinely useful behavior beyond those annotations: document formats are converted to text, while other binaries like images are returned as base64. It does not address limits or error behavior for unsupported types, but the core transformation behavior is well disclosed.

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?

Two sentences with no filler. The core action is front-loaded, and the format-conversion behavior is the only additional detail, which is exactly what an agent needs to anticipate the output shape.

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 read-only fetch tool with no output schema, the description sufficiently covers what will be returned: text for common document formats and base64 for other binaries. It could be more complete by specifying behavior for unsupported file types and clarifying that this applies to regular mail rather than shared mailboxes, but the essential call flow is understandable.

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 100%, so the schema already describes each parameter, including fileName's role in selecting the text extractor. The description enriches that context by explaining the text-vs-base64 conversion, but messageId and attachmentId remain only generically described as 'Value for ...' in the schema and are not expanded here.

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 ('Download an attachment') and the resource ('attachment'), and it describes the output as the attachment's content. It adds helpful format detail (text vs base64) but does not explicitly distinguish this from the sibling get-shared-mailbox-attachment-content; differentiation relies on the tool names.

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 usage is implied: after listing attachments, call this tool to fetch content. However, the description gives no explicit when-to-use/when-not-to-use guidance and does not mention the shared-mailbox sibling, so an agent must infer which tool applies rather than being told.

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 read-only, idempotent, and non-destructive behavior. The description adds a useful return-related detail ('including its full body'), but it does not describe default fields, body format, or other response behaviors. It adds some value beyond annotations but is not rich.

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 with no filler or redundant information. It front-loads the action and resource, then immediately adds the key detail about the full body. 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?

For a low-complexity tool with fully documented parameters and strong safety annotations, the description is nearly sufficient for an agent to invoke the call correctly. It could be more complete by explicitly noting how to obtain a messageId or that shared mailbox messages should go through the dedicated shared-mailbox sibling, but those are inferable from the schema and sibling names.

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 complete descriptions for both parameters (100% coverage), including the OData $select behavior for 'select' and the role of 'messageId'. The description adds little parameter-level meaning beyond confirming that the full body is included, so the baseline score 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 clearly states the action ('Get') and the resource ('a single message'), and adds a meaningful detail that the full body is included. It is clear, but it does not explicitly differentiate from closely related siblings such as get-shared-mailbox-message or list-mail-messages.

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?

No guidance is provided on when to use this tool versus alternatives like list-mail-messages or get-shared-mailbox-message. There is also no mention of prerequisites, such as obtaining a messageId from a list call, or exclusions for shared mailbox scenarios. The usage context is only implicit.

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 the operation is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying the output format (WebVTT) and that the full transcript text with speaker and timestamps is returned, which goes beyond the annotation-only information.

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?

Two focused sentences with no filler. The first sentence front-loads the core behavior and output format, and the second provides practical usage guidance, making every word useful.

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 tool with two required string parameters and no output schema, the description covers the key return type and intended use. It could mention vague prerequisites, such as needing to first retrieve transcriptId from a list operation, but this is not a critical gap given the tool's simplicity.

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 100%, so the baseline is 3 even though the tool description adds no parameter-level details. However, the schema descriptions are only placeholder-level ('Value for meetingId'), so the description does not meaningfully enrich parameter semantics for an agent.

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 clear verb and resource: it gets the full text of a meeting transcript. It also distinguishes itself from list-style siblings by emphasizing that speaker, timestamp, and text are preserved in WebVTT format, so the agent can tell this is a content-fetching tool rather than a metadata-listing one.

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 explicitly states intended use cases: meeting summaries, decisions extraction, and commitments extraction. It does not name alternative tools or give exclusion criteria, but the use-case guidance is clear enough for an agent to decide when this tool is relevant.

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. The description adds context about what data is returned (drive id, quota, owner), which is useful, but does not disclose failure modes, prerequisites, or response structure. It does not contradict 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?

A single, front-loaded sentence that conveys the resource, scope, and key output fields without any filler. 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?

For a simple, zero-parameter, read-only tool with rich annotations, the description is largely complete. It lists the key returned fields since there is no output schema. A minor gap is not explaining the exact response shape or edge case (e.g., user without OneDrive), but the core information an agent needs to select and invoke the tool is present.

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, so the schema is trivially complete. The description appropriately focuses on return values rather than parameters, matching the baseline for a parameterless tool.

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 names a specific verb ('Get'), a specific resource ('the signed-in user's OneDrive'), and the key returned data ('drive id, quota, owner'). This clearly distinguishes it from siblings like 'get-drive' and 'list-site-drives' by scoping it to the current user's default drive.

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 'signed-in user's OneDrive' implies when to use this tool—when you need the current user's default drive—but it does not explicitly state when not to use it or mention alternatives like 'get-drive' for a specific drive ID. Usage guidance is implied rather than stated.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral detail beyond annotations: the downloadUrl inclusion for files. It does not however describe folder behavior, response shape, or any limitations, which would be valuable without an output schema.

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 gets straight to the point, with no wasted words. It is front-loaded with the action and resource.

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 one-parameter, read-only metadata retrieval tool with rich annotations, the description is mostly complete. It names the resource and a key return detail (downloadUrl). The main gaps are lack of guidance on itemId provenance and no explicit distinction from the download-focused sibling tools, but the low complexity keeps this from being a major deficiency.

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 100% with a single itemId parameter, so the schema carries most of the parameter burden. The description does not explain how itemId should be obtained or how file versus folder behavior affects the call, but it also does not need to compensate heavily given the simple input 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 states a specific verb ('Get'), a clear resource ('OneDrive file/folder metadata'), and adds a useful distinguishing detail about @microsoft.graph.downloadUrl for files. It is clear on its own, though it does not explicitly contrast with sibling tools like get-drive-item or get-my-drive-item-download-url.

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?

No guidance is provided on when to use this tool versus closely related siblings such as get-drive-item, download-my-drive-item, get-my-drive-item-download-url, or the list-my-drive-* tools. The description does not state any selection criteria or exclusions.

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 read-only, idempotent, and non-destructive behavior. The description adds genuinely new behavioral context: the URL is short-lived and direct, and no content is fetched. It does not quantify 'short-lived' or mention auth requirements, but it provides useful traits beyond 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?

A single, well-constructed sentence that front-loads the key result (short-lived direct download URL) and immediately contrasts with content fetching. There is no wasted wording 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 one-parameter tool with no output schema, the description explains the essential return value (a URL) and its transient nature. It does not specify how short-lived the URL is or whether additional authentication is needed, but the tool is simple enough that these are minor gaps.

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 100% for the single itemId parameter, so the baseline is 3. The description adds little about the parameter itself beyond associating it with a OneDrive file. The schema's own description 'Value for itemId' is also minimal, so the description does not meaningfully compensate or expand.

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 names a specific verb and resource: it gets a short-lived direct download URL for a OneDrive file. It also explicitly distinguishes itself from content-fetching tools by adding 'without fetching its content', which separates it from siblings like download-my-drive-item.

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 clearly implies when to use this tool: when a URL is needed rather than the file content. It does not explicitly name an alternative tool, but the 'without fetching its content' phrasing sets the boundary against download tools. This is clear context, though not an explicit when-not/alternative statement.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no behavioral context beyond the operation itself, such as returned data shape, error behavior, or what 'notebook' includes.

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 clear sentence with no filler or redundant phrasing. It front-loads the core action and resource effectively.

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 one-parameter, read-only tool, the description plus annotations and schema are largely sufficient to invoke it correctly. The only notable gap is the lack of any statement about what the returned notebook object contains, especially since no output schema is provided.

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 100%, and the only parameter, notebookId, is documented directly in the schema. The description does not add extra meaning about the parameter format, source, or lookup semantics, so the baseline score of 3 applies.

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 'Get a single OneNote notebook' uses a specific verb and resource and notes the singleton scope, which differentiates it from the sibling list-onenote-notebooks. An agent can immediately tell this is a fetch-by-id operation rather than a listing operation.

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 explicit guidance about when to prefer this tool over alternatives such as list-onenote-notebooks. The word 'single' weakly implies use when a specific notebookId is known, but no conditions, exclusions, or alternative tool names are 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, covering the safety profile. The description adds useful context about the metadata-only scope and directs the agent to the content tool, but it does not disclose what metadata fields are returned or whether any rate limits or auth requirements apply. This matches the baseline expected when annotations cover safety.

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?

Two short sentences each earn their place: one states the tool's purpose, the other names the sibling for content retrieval. There is no repetition 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 simple single-parameter metadata read tool, the description is mostly complete: it says what is returned at a high level, points to the content counterpart, and annotations cover safety. It would be stronger if it enumerated the metadata fields or noted the absence of an output schema, but an agent can likely infer the scope correctly from 'metadata.'

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?

There is only one parameter, pageId, and the schema description covers it 100% with 'Value for pageId.' The description adds no additional meaning about the parameter beyond the schema, 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?

Description uses a specific verb and resource: 'Get metadata of a OneNote page.' It also distinguishes itself from get-onenote-page-content by explicitly stating that the content tool is for the body. An agent can immediately tell this tool is for metadata only.

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 clearly indicates that this tool is appropriate for metadata and that get-onenote-page-content should be used for the actual body. It stops short of explicitly discussing when to prefer this over other OneNote listing or search tools, but it gives clear contextual guidance for the most likely alternative.

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 the tool read-only, idempotent, and non-destructive. The description adds that the return value is full HTML content for the actual note body, which is not visible in the schema. This is sufficient behavioral context for a safe read operation.

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 with no filler. It front-loads the action and resource, then adds the useful contrast with metadata. Every clause 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?

For a one-parameter, read-only tool with strong annotations and no output schema, the description is complete. An agent knows what the tool returns, what it does not return, and what input is required. No crucial operational details are missing at this simplicity level.

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 100%, so the baseline is 3. The description adds no extra meaning about pageId, and the schema's 'Value for pageId' is tautological, but the single required parameter is self-evident from its name and the tool's purpose.

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 names a specific verb and resource: get the FULL HTML content of a OneNote page. It explicitly contrasts with metadata, which separates it from sibling tools like get-onenote-page. There is no ambiguity about what this tool does.

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 'not just metadata' tells an agent this tool is for retrieving the actual note body, implying the alternative is a metadata-focused OneNote page tool. It does not explicitly name the sibling tool or address the site-scoped variant, but it provides enough context for the common selection decision.

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 annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds which meeting fields are included, but it does not disclose behavioral details like not-found behavior or response shape. Given the annotations, this is adequate but not exceptional.

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, focused sentence with no redundant phrasing. The verb, resource, lookup key, and expected fields are all front-loaded, making it easy for an agent to parse quickly.

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 get-by-id tool with one clearly described parameter, the description is nearly complete. It covers the lookup key and returned fields. It could be improved by explicitly noting that it returns a single meeting object or by directing users to find-online-meeting-by-join-url when only a join URL is available.

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 100%, but the schema's description for meetingId is just 'Value for meetingId', which is uninformative. The tool description adds real meaning by clarifying that the parameter is an onlineMeeting id and indicating the data associated with it.

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 ('Get'), names the exact resource ('online meeting'), and specifies the lookup key ('onlineMeeting id'). It also lists the key fields returned, making the tool's purpose unmistakable and distinguishing it from sibling tools like find-online-meeting-by-join-url.

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 this tool should be used when the caller already has an onlineMeeting id, which is clear context. However, it does not explicitly mention alternatives such as find-online-meeting-by-join-url or state when not to use this tool.

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 mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying that it returns availabilityView values and busy time slots, and by disclosing the privacy behavior around event details. It does not contradict 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?

Two tight sentences deliver a specific purpose, the exact return format with enum meanings, and the key privacy limitation. Every clause earns its place and the most important information is front-loaded.

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 read-only availability tool with no output schema, the description gives enough return semantics through the availabilityView values and busy time slots. It also covers the critical edge case of hidden event details, making the tool's behavior predictable 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 100%, so the schema already documents all parameters. The description adds only general context such as 'time window' for start/end and 'colleagues' for emails, but does not meaningfully enrich parameter-specific semantics beyond 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 identifies the operation as retrieving free/busy availability (getSchedule) for one or more colleagues' calendars over a time window. It also distinguishes itself from event-detail tools by noting that event details stay hidden unless the calendar is shared.

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: when checking colleagues' availability for a time window. It also conveys an implicit when-not-to-use condition by noting event details are hidden unless the calendar is shared, though it does not explicitly name alternative 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 establish read-only, idempotent, and non-destructive behavior, so the description's additional disclosure that this performs text extraction rather than raw binary download is valuable context. The hint that fileName helps pick the right text extractor further clarifies behavioral 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 sentence that front-loads the core action and resource, with a useful parenthetical reference to the sibling tool. There is no wasted or redundant wording.

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, all required parameters are well-documented in the schema, and annotations cover the safety profile. The description sufficiently conveys the extraction behavior. It does not explain the relationship with get-mail-attachment-content in depth, but for this read-only, fully-schema-covered tool the core information is present.

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 100% parameter documentation, so the schema already carries most of the semantic burden. The description adds little beyond the parenthetical text-extraction behavior, and the fileName parameter's role is already stated in 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 action (download an attachment) and the resource scope (shared-mailbox message), which distinguishes it from get-mail-attachment-content. However, the parenthetical merely says 'like get-mail-attachment-content' rather than explicitly explaining how the two tools differ, so differentiation is good but not fully spelled out.

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 this tool should be used for shared-mailbox attachments and that it performs text extraction much like get-mail-attachment-content. It does not explicitly state when to choose this tool over its close sibling, nor does it mention a prerequisite such as first listing attachments to obtain attachmentId.

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 communicate read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds a meaningful behavioral detail beyond the schema: the response includes the full message body, which is useful in the absence of an output schema.

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 sentence with no redundant phrasing; the key facts (single message, shared mailbox, full body) are front-loaded and 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?

For a simple single-get tool with full schema coverage and safety annotations, the description is sufficient to invoke it correctly. The only minor gap is the absence of routing guidance versus get-mail-message and the list variant, but the tool name and sibling list compensate.

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 100%, so mailbox, messageId, and select are already documented. The description adds no parameter-level detail beyond the resource type, so the baseline of 3 applies.

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?

Describes a specific operation: retrieving one message from a shared mailbox, and notes it includes the full body. The 'single' qualifier and 'shared-mailbox' resource clearly distinguish it from list-shared-mailbox-messages and get-mail-message.

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 'single shared-mailbox message' implies the tool is for a targeted fetch rather than listing, so usage is inferable. However, no alternatives or exclusion conditions are mentioned (e.g., use get-mail-message for user mailboxes or list-shared-mailbox-messages for multiple messages).

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, so the safety profile is established. The description adds a useful detail about accepted identifier forms, but does not disclose other behavioral traits such as error behavior, result shape, or relationship to openWorldHint.

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, tightly scoped sentence that front-loads the verb and resource, then clarifies the input format. There is no filler or redundant restatement of the tool name.

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 one-parameter read-only tool with rich annotations, the description is nearly complete: it states what the tool does and how the identifier is expressed. The lack of an output schema is acceptable here, though a brief note about the returned site object could have made it fully self-contained.

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 only describes siteId as 'Value for siteId', which is unhelpful. The description adds real semantic value by explaining that siteId can be either a plain id or a hostname:/sites/path form, going beyond what the schema alone provides.

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 operation as retrieving a SharePoint site by identifier, using a specific verb and resource. It does not explicitly differentiate itself from sibling tools like search-sites or get-site-list, but the focused 'by id' wording makes the core purpose 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 implies the tool is appropriate when the caller already has a site id or a hostname:/sites/path reference. However, it offers no explicit guidance about when to prefer this over search-sites or other related site tools, and no exclusions or alternatives are 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. The description adds no additional behavioral context such as permission requirements, return shape, or pagination, but for a simple read operation the annotations carry most of the burden.

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 six-word sentence with no filler, redundant phrasing, or unnecessary detail. It front-loads the action and resource immediately.

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 tool with two IDs, a non-destructive annotation set, and a single known resource, the description is largely sufficient. It could add a note about what is returned or how it differs from listing lists, but those are minor omissions for this level of complexity.

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 100%, so the parameters are at least documented. The description adds the shared semantic that both parameters together identify the target list, which is mildly useful, but it does not explain the relationship between siteId and listId or the expected format beyond the schema baseline.

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 clear verb ('Get'), a specific resource ('a SharePoint list'), and the identifying mechanism ('by id'). This distinguishes it from siblings like list-site-lists (enumerating lists) and get-site-list-item (getting an item within a list) without needing to inspect schemas.

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?

Usage context is only implied: use this when you have a siteId and listId. There is no explicit guidance on when to prefer list-site-lists or get-site-list-item instead, and no exclusions or alternatives are named.

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 readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds the behavioral detail that field values are included in the result, which is useful in the absence of an output schema. It does not contradict 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?

A single, front-loaded sentence that states the tool's core action without filler or redundancy. Every word contributes to meaning, and it is appropriately sized for a simple read operation.

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 tool with clear parameter names and safety-bearing annotations, the description is largely sufficient. It specifies the return contains field values, though it does not detail response structure or explicitly route to list-based siblings. This is a minor gap given the tool's simplicity.

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 100%, so the baseline is 3. The schema property descriptions are placeholder-like ('Value for itemId'), but the parameter names siteId, listId, and itemId are self-explanatory, and the description adds SharePoint item context. No additional semantic meaning is provided beyond that.

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 a specific verb ('Get') and a specific resource ('a single SharePoint list item'), and the qualifier 'single' distinguishes it from the sibling list-site-list-items. It is immediately understandable and not a tautology.

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 it — when a single SharePoint list item is needed by ID — but it does not explicitly mention alternatives like list-site-list-items for multiple items or get-site-list for list metadata. Usage context is inferable, not stated.

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 description does not need to repeat safety. It adds the useful behavioral detail that the response is full HTML content, but gives no further context on format, size, or output representation.

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 entire description is one short, front-loaded sentence with no filler. Every word adds signal: Get, FULL HTML content, SharePoint-hosted, OneNote page.

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 read-only, idempotent tool with two fully documented parameters and no output schema, the description covers the essential retrieval purpose and return type. It would be slightly stronger if it named the sibling for personal OneNote pages, but the SharePoint-hosted qualifier carries most of that burden.

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 100%, so the schema already documents the two required parameters. The description adds only the SharePoint-hosted context, which the siteId schema description already conveys; no additional parameter semantics are needed.

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 action ('Get'), exact resource ('OneNote page'), and scope ('SharePoint-hosted', 'FULL HTML content'). The qualifiers distinguish it from the sibling get-onenote-page-content without requiring the agent to infer from the name.

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 the tool is for SharePoint-hosted pages rather than personal OneDrive pages, but it never states when to choose it over get-onenote-page-content or other site-onenote siblings. No exclusions or alternative-selection guidance 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 convey that this is read-only, idempotent, and non-destructive, so the description does not need to repeat that safety profile. It adds only the return scope ('properties') and stays consistent with the annotations, but it does not disclose error behavior, authorization needs, or response details.

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, direct sentence with no wasted words. It conveys the essential operation and resource in the minimum viable space.

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: one required parameter, no nested objects, and safety-relevant annotations are present, so an agent can invoke it correctly. Still, with no output schema, the description does not say what 'properties' will be returned or what happens when the teamId is invalid, and it gives no context about when to use this tool versus related team tools.

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 100% description coverage for its single parameter, so the baseline is met even though the tool description adds no parameter meaning. The schema's own 'Value for teamId' is tautological, and the description does not clarify where teamId comes from or what format it expects, but no additional descriptive burden is required due to the high coverage.

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 ('Get') and the resource ('a team's properties'), so an agent can tell it deals with a single team's metadata rather than channels or messages. However, it does not explicitly differentiate itself from related siblings like list-joined-teams or get-team-channel.

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 get-team versus alternatives such as list-joined-teams for enumerating teams or get-team-channel for specific channel details. An agent must infer the intended usage from the tool name alone.

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 the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no further behavioral context such as error behavior, permissions, or whether the channel must belong to the current user's team.

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, front-loaded sentence with no filler. Every word earns its place and the core action is immediately understandable.

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 operation with two required, fully documented string parameters and strong annotations, the description is largely sufficient. It could explicitly state that the tool returns the channel object, but the verb and resource make the result fairly predictable.

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 100%, so teamId and channelId are already documented by the schema. The description's 'channel of a team' loosely maps to these parameters but contributes no additional semantic or format 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 uses a clear verb ('Get') and resource ('single channel of a team'), and the word 'single' helps distinguish it from the sibling list-team-channels. However, it does not explicitly name or contrast any alternative tools.

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?

No guidance is given about when to choose this tool over siblings such as list-team-channels, get-team, or get-channel-message. The intended use case is only implied by the resource name and parameter schema.

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 the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description does not add much behavioral context beyond identifier-based lookup, and it does not disclose return shape or error behavior, though the missing output schema makes that a moderate gap.

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 that conveys the core purpose with no unnecessary words. It earns its place entirely.

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 lookup with complete parameter documentation and safety annotations, the description is mostly sufficient. It could mention the return shape, but the tool name and 'Get a user' make the outcome reasonably clear.

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 100%, so the schema already documents both userIdOrUpn and select. The description adds little beyond restating that the identifier can be an object id or UPN, which is already present in 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 states a clear, specific action: fetch a single user by object id or userPrincipalName. This makes it easy to distinguish from sibling lookup tools like list-users and search-users, which operate over collections or query terms.

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 the tool should be used when a known user identifier (object id or UPN) is available, but it does not explicitly contrast with list-users or search-users. The usage context is inferable rather than explicitly stated.

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?

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds substantial behavioral detail: it reads a specific audit category, filters to only accountEnabled changes, returns newest first, states the 30-day/7-day retention with explicit 'not available' behavior for older changes, and lists required permissions. This far exceeds what annotations alone convey.

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 dense but every sentence adds value: the opening question frames the purpose, the middle details the exact audit events and retention, and the end covers permissions and read-only nature. No fluff or repetition of schema content; it is structured to front-load the core function.

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 read-only query tool with rich annotations and a fully documented schema, the description covers all essential contextual aspects: what events are returned, what is excluded, ordering, retention limitations, and authorization requirements. Even without an output schema, it conveys the result shape conceptually ('by whom, with what result').

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 100%, and the schema already documents all seven parameters including enums and pagination. The description adds no parameter-specific semantics beyond the overall filtering behavior, so it stays at the baseline 3 without needing to compensate for undocumented 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 uses a specific verb and resource: it 'Reads the Entra directory audit log (category UserManagement) for the given user and returns only the events that changed accountEnabled'. It clearly names the activities ('Disable account'/'Enable account', 'Update user' events) and distinguishes itself from the more general sibling list-directory-audits by focusing solely on accountEnabled changes for one user.

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 strong context on what the tool does and its scope, including that 'Other user updates are excluded' and that it is user-specific. It does not explicitly name the alternative (list-directory-audits) or state when not to use it, but the clear scope and filtering semantics effectively imply the appropriate use case.

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 readOnly, idempotent, and non-destructive. The description adds useful non-obvious behavior: this tool returns series masters and single events rather than expanded recurrences, and it is limited to the default calendar. It does not describe return shape, but the schema covers pagination semantics.

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 exactly two sentences with no filler. The core functionality is front-loaded, and the routing guidance is expressed in one compact clause.

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 plus fully documented schema provides enough for an agent to select and invoke the tool correctly: scope, recurrence behavior, and the key alternative are all covered. A small gap is the lack of any explicit statement about the response format, though the pagination-related parameters imply list semantics.

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?

All 5 parameters have detailed descriptions in the schema, so schema coverage is 100% and the baseline is 3. The description adds no parameter-specific detail, but none is needed because the schema already documents cursor, filter, select, orderby, and maxItems clearly.

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 and resource: 'List events of the default calendar', and further clarifies the scope with '(series masters + single events)'. It also distinguishes itself from the sibling get-calendar-view by noting that the sibling expands recurrences.

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 explicitly tells agents when to prefer an alternative: 'For time-ranged queries prefer get-calendar-view which expands recurrences.' This gives a clear when-not-to-use signal and names the relevant sibling tool.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the behavioral scope 'the signed-in user's calendars,' clarifying whose data is returned, which is beyond what annotations state. No additional behavioral detail (e.g., result freshness, defaults, or error behavior) is provided, but the lower bar for annotation-covered tools makes this adequate.

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 sentence, 'List the signed-in user's calendars,' contains zero filler and front-loads the verb before the resource. The schema handles parameter documentation, so the description's brevity is appropriate rather than under-specified.

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 low-complexity read-only tool with zero required parameters and fully self-documenting schema, the description plus annotations cover everything needed to invoke it correctly. The absence of an output schema means the return shape of calendar objects is undocumented, and no tool-level mention of pagination exists (though it is well covered in the schema parameter descriptions), leaving minor gaps.

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 100%: both cursor and maxItems have detailed descriptions in the input schema, including the continuation-token semantics and the pagination behavior via @odata.nextLink. The tool description itself adds no parameter information, but the baseline of 3 applies since the schema carries the full burden and does so well.

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 ('List') and a specific resource ('the signed-in user's calendars'), making the core function immediately clear. The scope qualifier 'signed-in user's' distinguishes this from shared-mailbox or site-oriented tools, and 'calendars' (rather than events) separates it from list-calendar-events. However, it stops short of explicitly naming sibling tools it is not, so differentiation is implicit rather than stated.

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 the many calendar-related siblings such as get-calendar, get-calendar-view, list-calendar-events, or get-calendar-event. No exclusions or alternative routing are given, leaving an agent to infer selection purely from the tool name. Given the high ambiguity among sibling calendar tools, this is a notable gap.

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 the operation read-only, idempotent, and non-destructive, so the description does not need to repeat those traits. The description adds limited behavioral context beyond identifying replies as a thread; pagination semantics are described in the input schema rather than the description.

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 clearly conveys the operation and target resource with 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?

For a read-only list operation with fully documented parameters and clear annotations, the description plus schema is nearly complete. It lacks only an explicit statement about the response shape or how truncation behaves, though maxItems and cursor provide substantial pagination 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?

The input schema covers 100% of parameters, including detailed descriptions for cursor and maxItems. The description itself adds no parameter-level meaning, so the baseline score of 3 applies.

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 the exact operation ('List') and the specific resource ('replies (thread) of a channel message'), making it clearly distinct from sibling tools like list-channel-messages or get-channel-message. Even without naming alternatives, an agent can infer what this tool targets.

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 action implies the use case: retrieve replies to a specific channel message. However, the description does not explicitly state when to prefer this tool over similar list/get message tools, nor does it mention any exclusions or alternatives.

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 signal read-only and idempotent behavior, and the description adds value by stating the newest-first ordering and the important Graph limitation that server-side filtering is unsupported. This prevents the agent from expecting filter parameters or trying to use this tool for keyword queries.

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 with a parenthetical that provides the key caveat and routing to the alternative. There is no wasted text or repetition of schema content.

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 plus the well-documented maxItems/cursor parameters gives enough context to invoke the tool correctly, including ordering and truncation continuation. It does not describe the message return shape, but no output schema is present and the list semantics are reasonably clear from the wording.

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 100%, so the schema carries the parameter documentation burden. The description does not add parameter-level details beyond the schema, which warrants the baseline score of 3.

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 and resource ('List messages of a team channel') and adds the useful ordering detail 'newest first'. It also explicitly differentiates from the keyword-search sibling by naming search-m365, so an agent can identify what this tool is and is not for.

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 clearly states when to use the tool (listing team-channel messages) and gives an explicit alternative for keyword search: 'use search-m365 for keyword search.' It does not enumerate exclusions against other siblings such as list-channel-message-replies, so it stops short of a full 5.

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. The description adds genuine behavioral value beyond that: the newest-first ordering and, crucially, the disclosure that keyword filtering is not supported server-side — a real limitation an agent would otherwise discover only after a failed call.

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?

Two sentences with zero filler: the core action and ordering are front-loaded, followed by the time-range capability and the keyword-filter caveat. Every sentence 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?

For a read-only listing tool with full schema coverage and rich annotations, the description is nearly complete: it covers scope, ordering, filtering, and the biggest behavioral gotcha (no server-side keyword filtering). No output schema exists, and the schema's maxItems description already handles pagination semantics, so little is missing.

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 100%, so the schema already documents all six parameters, including the from/to/timeRange semantics and cursor behavior. The description's mention of 'lastModifiedDateTime filter' largely restates what the schema's timeRange description already says, adding little parameter-level meaning beyond that baseline.

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?

States a specific verb and resource — 'List messages of a chat' — plus the ordering behavior 'newest first'. This distinguishes it from list-chats (lists chats themselves), get-chat-message (single message), and list-channel-messages (channel, not chat, messages), though it doesn't name those siblings explicitly.

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?

Provides clear context for when the tool applies (listing chat messages with an optional time range) and explicitly routes keyword-filtering use cases away: 'Keyword filtering must be done client-side or via search-m365 with entityTypes=["chatMessage"]'. It could additionally point to get-chat-message for single-message retrieval, but the main cross-tool ambiguity is handled.

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 the read-only, idempotent, non-destructive safety profile, so the bar is lower. The description adds useful scoping (signed-in user, chat types) but does not disclose behavioral details like ordering, truncation, or how the open-world result set behaves; those are partly covered by parameter docs.

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 with no filler. Every word contributes to identifying the resource and scope, and the parenthetical chat types add precise value without bloating the text.

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 read-only list tool with five optional, well-documented parameters and comprehensive safety annotations, the description is nearly complete. It lacks an explicit statement of the return shape, but 'List' plus the resource specification is sufficient guidance, and pagination/filtering behavior is covered in the 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 description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level information, but every parameter (cursor, filter, select, orderby, maxItems) is already well documented in the schema, so no gap exists.

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 ('List'), a specific resource ('the signed-in user's Teams chats'), and enumerates the chat subtypes (1:1, group, meeting chats), making it clearly distinct from sibling tools like list-chat-messages or list-mail-messages.

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 the usage scenario — enumerating the signed-in user's Teams chats — and the scope is clear, but it does not explicitly mention alternatives or when not to use this tool, such as using get-chat for a single chat or list-chat-messages for messages within a chat.

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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds meaningful behavioral context: the operation is read-only, requires specific admin-consented permissions (AuditLog.Read.All + Directory.Read.All), and only covers a 30-day retention period. This helps the agent set expectations about data availability and authorization.

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 dense but well-organized, front-loading the tool's purpose before moving to filter syntax, retention, and permissions. Every sentence adds useful information, and there is no fluff or repetition of schema content.

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 read-only audit listing tool with seven optional parameters and no output schema, the description provides enough context to call it correctly: what the log contains, how to filter, the time field, retention limits, and required permissions. Pagination behavior is already covered in the input schema, so nothing essential is missing.

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?

Although schema description coverage is 100%, the description adds significant value by giving domain-specific $filter examples that correct the generic mail-oriented filter example in the schema. It also clarifies that timeRange/from/to apply to activityDateTime, giving the agent precise parameter semantics for audit queries.

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 identifies the resource as the Entra directory audit log and specifies exactly what it contains: who changed what and when, for users, groups, apps, password resets, and role assignments. This clearly distinguishes it from the sibling tools, none of which cover directory audit log retrieval.

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 concrete usage guidance: time filtering applies to activityDateTime and includes realistic $filter examples for category, activityDisplayName, and targetResources. It also states the retention window and required permissions. It does not name alternative tools to switch to, but no direct sibling alternative exists among the listed 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 cover readOnlyHint, idempotentHint, and destructiveHint. The description adds no behavioral context beyond the basic operation, such as whether the listing is non-recursive, whether it returns metadata only, or how pagination/truncation behaves.

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, tight sentence with no filler. It front-loads the verb and resource scope, making the tool's purpose immediately readable.

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 read-only listing tool with a fully documented schema and safety annotations, the description is mostly sufficient. However, it does not clarify whether the listing includes only immediate children or recursive contents, and it gives no orientation relative to sibling list/search tools.

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 100%, and parameters like cursor, maxItems, filter, and select are already well-documented in the schema. The description contributes no additional parameter semantics, so the baseline score applies.

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 an explicit verb ('List') and a specific resource ('files/folders inside a folder of a drive'). This clearly distinguishes it from sibling tools like list-drive-root-items, which list the root, and search-drive-items, which search across a drive.

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 such as list-drive-root-items, list-my-drive-folder-items, or search-drive-items. The description only states what the tool does and does not provide conditions, exclusions, or context for choosing it over siblings.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context such as truncation, continuation, non-recursive listing, or default ordering; it only restates the resource scope.

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 filler. The parenthetical '(document library)' earns its place by disambiguating the term 'drive' in the Microsoft Graph context.

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?

As a read-only list tool with well-documented parameters and informative annotations, the definition is minimally viable. However, it omits any mention of when to use this over sibling list tools, and with no output schema the agent receives no guidance on return shape or pagination beyond what the maxItems parameter description already states.

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 100%, so the baseline of 3 applies. The tool description itself adds no parameter-level meaning beyond what the schema already provides for driveId, cursor, filter, select, orderby, and maxItems.

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 ('List') and a specific resource ('files/folders in the root of a drive'), and clarifies that 'drive' means a document library. It is unambiguous, but it does not explicitly distinguish itself from sibling tools like list-drive-folder-items or list-my-drive-root-items, so differentiation relies mostly on the tool name.

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 such as list-drive-folder-items or list-my-drive-root-items. There are no explicit conditions, exclusions, or references to sibling tools, leaving the agent to infer usage from the name alone.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the metadata qualifier and no additional behavioral context such as pagination side effects or authorization needs, but it does not contradict 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 a single, front-loaded sentence with no filler. It communicates the core action, resource, and metadata scope efficiently, letting schema and annotations carry the remaining detail.

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 listing tool, the description plus schema and annotations cover invocation essentials: required eventId, pagination semantics, and safety characteristics. The only minor gap is the absence of explicit guidance on when to use this tool versus related resource-specific attachment tools, but that is not critical for correctness.

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 100% and the parameters already include detailed descriptions, including pagination behavior via cursor and maxItems. The tool description adds no parameter-level information beyond what the schema provides, so the baseline score 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 ('List'), a specific resource ('attachments of a calendar event'), and adds the qualifier 'metadata' so the agent knows it returns metadata rather than content. This clearly distinguishes it from sibling tools like list-mail-attachments or get-mail-attachment-content.

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 by the resource and metadata qualifier, but there is no explicit guidance about when to prefer this tool over alternatives or when not to use it. For example, it does not mention that attachment content retrieval would require a different tool, though no such sibling exists for calendar events.

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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat them. The description adds the useful 'signed-in user' scoping behavior but does not disclose pagination behavior or response shape; with strong annotations, this is acceptable but not exceptional.

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, focused sentence with no filler or repetition. Every word contributes to understanding the tool's purpose and scope.

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 list operation with rich annotations and fully documented parameters, the description is mostly complete. It does not describe the return value format, but the verb 'List' makes the general response shape clear, and no output schema is available.

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 100%, and both cursor and maxItems have detailed schema explanations. The description does not add parameter-level meaning, which is fine because the schema already carries the full burden.

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 ('List') and a clear resource ('Microsoft Teams teams the signed-in user is a member of'), which precisely distinguishes this tool from siblings like get-team and list-team-channels. It is immediately obvious what the tool does and what scope it covers.

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: it is for listing the signed-in user's team memberships. It does not explicitly name alternatives or exclusion conditions, but the scope is unambiguous enough for an agent to know when 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 the behavioral trait that only metadata is returned, which is beyond the readOnly/openWorld/idempotent/destructive annotations. It does not contradict the annotations, and the annotations already cover the safety profile, so this additional scoping is valuable though not exhaustive.

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 states the verb, object, and return scope with no filler. 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?

For a list-only tool, the description plus schema and annotations cover the required messageId, optional pagination parameters, read-only behavior, and return fields (metadata only). Nothing essential is missing for an agent to call it correctly.

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 100%, with all three parameters (messageId, cursor, maxItems) described in the input schema. The description adds no parameter-specific meaning beyond the schema, so a baseline 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 clearly states the specific action (List), resource (attachments of a message), and a crucial scoping detail (metadata only, with the exact fields returned). This distinguishes it from sibling tools like get-mail-attachment-content and list-event-attachments.

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 'metadata only: name, contentType, size' communicates the appropriate use case—listing attachment summaries without content—so an agent can infer when not to use this tool. However, it does not explicitly name the content-retrieval sibling (get-mail-attachment-content) or provide exclusion criteria, stopping short of a 5.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'List' action is consistent with these. The description adds no behavioral detail beyond the annotations—it does not mention pagination, truncation, or scope of children—though these are partially covered by the parameter schema.

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 with no filler or repetition. It states the essential action and resource directly, earning its place despite being terse.

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 listing tool with 100% schema coverage and safety annotations, the description is mostly complete. It could be improved by explicitly stating that only immediate child folders are returned and by referencing list-mail-folders as the source of folderId, but the schema and tool name cover most of this context.

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 100%, so the parameters are fully documented in the schema. The tool description itself adds no parameter-level meaning, but the schema already explains folderId, cursor, and maxItems, so a baseline score 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 uses a specific verb ('List') and resource ('child folders of a mail folder'), making the tool's basic purpose clear. It implicitly distinguishes from siblings like list-mail-folders by emphasizing child folders, but it does not explicitly name that sibling or the boundary between them.

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 list-mail-folders or list-shared-mailbox-folders. The required folderId and the phrase 'of a mail folder' imply the parent-folder context, but there is no explicit when-to-use or alternative routing.

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. The description adds only that the tool supports both listing and searching, but does not disclose pagination behavior, cursor semantics, or OData/KQL filtering traits, which are left to the parameter schema.

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 with no wasted words. Action and scope are front-loaded, allowing an agent to quickly understand the tool's purpose without digging through the schema.

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 a rich schema, the tool description is minimal for a 10-parameter operation. It omits the pagination contract, the full-text search and OData filter capabilities, and does not clarify how this tool differs from shared-mailbox or top-level mail listing siblings. The schema and annotations cover invocation details, but the description leaves selection ambiguity among closely related tools.

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 100%, and every parameter carries a meaningful description. The tool description merely echoes 'search' capability that already exists in the search/filter parameters, adding no value beyond the schema. Baseline 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 clear action ('List/search') and a specific resource scope ('messages inside a specific mail folder'). This distinguishes it from broader siblings like list-mail-messages, which operate on the whole mailbox, and aligns with the required folderId parameter.

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 scope of 'specific mail folder' implies when to use it, but there is no explicit guidance contrasting it with alternatives such as list-mail-messages or list-shared-mailbox-folder-messages. An agent must infer the intended context rather than being told directly.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description's mention of 'List' aligns with read-only behavior but adds little behavioral detail beyond the purpose.

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 conveys the exact scope and resource with no filler. 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?

For a simple read-only list operation with rich annotations, detailed parameter schema, and clear scoping, the description is complete. An agent can select and invoke it correctly without additional context.

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?

Input schema has 100% parameter description coverage, clearly explaining cursor and maxItems including defaults, max values, and pagination behavior. The description itself adds no parameter-level information, so baseline 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?

Description specifies a clear verb ('List') and resource ('top-level mail folders of the signed-in user's mailbox'). Scoping to top-level and signed-in user distinguishes it from siblings like list-mail-child-folders and list-shared-mailbox-folders.

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 clearly implies when to use it: for top-level folders in the signed-in user's own mailbox. It does not explicitly name alternatives or exclusion conditions, but the scope wording effectively separates it from shared-mailbox and child-folder 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that full-text KQL search and time ranges are supported, which is useful but not deeply behavioral. No contradiction with annotations exists.

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 focused sentence that front-loads the core action and resource, then names the key capabilities. Every word contributes value and there is no redundant 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 moderately complex tool with nine parameters, the description plus a fully covered schema is largely sufficient. It does not describe the output shape, and there is no output schema, but the schema covers pagination via maxItems/cursor and the description clearly conveys the tool's scope. Minor gap: it does not mention that omitting all filters returns all messages.

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 100%, so the schema documents all nine parameters thoroughly. The description adds high-level context about KQL and time ranges, but it mostly restates what the search and timeRange parameter descriptions already provide. This is the baseline for full schema coverage.

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 verb-resource pair: list/search messages in the signed-in user's mailbox, and adds specific capabilities (KQL full-text search and time ranges). It does not explicitly contrast with sibling tools like list-mail-folder-messages or list-shared-mailbox-messages, but the 'signed-in user's mailbox' scope distinguishes it from shared-mailbox variants.

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 the tool: for searching or listing messages in the signed-in user's mailbox with KQL or time-range filters. However, it gives no explicit guidance about alternatives such as list-mail-folder-messages for folder-scoped listing or get-mail-message for retrieving a single message, so the agent must infer the routing decision.

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 fully covered. The description adds useful behavioral context by specifying the kind of data returned—who joined, when, and for how long—which matters because there is no output schema.

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 compact sentence conveys purpose and key output semantics without redundancy. It is front-loaded with the verb and resource and contains no filler or repetition of the tool name.

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 listing tool, the description plus a fully documented schema and strong annotations cover the essentials. It does not explicitly explain how to obtain meetingId/reportId or mention sibling alternatives, but the required inputs are obvious from the schema and the description provides enough output context.

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 100%, and the schema already documents all parameters including cursor and maxItems pagination behavior. The description adds no new parameter-level meaning beyond framing the records as belonging to an attendance report, 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?

Description states a specific verb ('List'), a resource ('attendance records'), and clarifies the scope ('of an attendance report') with useful output details (who joined, when, for how long). This distinguishes it from the sibling list-meeting-attendance-reports, which lists reports rather than the records inside a report.

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 'of an attendance report' implies that meetingId and reportId are needed and that the caller should already have an attendance report. However, there is no explicit guidance about when to choose this tool over list-meeting-attendance-reports or related meeting tools, so usage is mostly implied rather than stated.

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, so the safety profile is covered. The description adds no behavioral nuance—such as report scope, permission requirements, or truncation behavior—beyond what annotations and schema already provide. There is no 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, front-loaded sentence with no wasted words. It clearly states the verb and resource in the fewest possible characters.

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 a nearly identical sibling tool, the description is too thin. It does not explain what an attendance report contains, how meetingId is obtained, or how these reports differ from list-meeting-attendance-records. Pagination details live in the schema, but the missing selection and return context makes this less than 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 input schema covers 100% of parameters, and cursor and maxItems have detailed, actionable descriptions. The tool description itself adds no parameter meaning, but the high schema coverage keeps this at the baseline. The meetingId schema description is weak, but the description does not compensate for it.

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 names the operation ('List') and the resource ('attendance reports') scoped to an online meeting, so an agent can tell what the tool does. However, it does not differentiate this from the near-identical sibling list-meeting-attendance-records, stopping just short of a 5.

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 when-to-use or when-not-to-use guidance, and no mention of alternatives such as list-meeting-attendance-records. The intended usage is only implied by the tool name and the phrase 'of an online meeting', not explicitly stated.

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 the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description adds value beyond them by disclosing that the tool returns only metadata plus a content URL, not the actual media — 'the recording itself stays in OneDrive/SharePoint.' This usefully sets expectations that no content download occurs. 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?

A single, front-loaded sentence that names the action and resource first, then adds a compact parenthetical with the most decision-relevant detail (metadata + URL; content stays remote). No filler or redundancy.

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