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

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), but the description adds the key behavioral fact that a browser sign-in flow may be triggered — a material side effect not captured in annotations. It stops short of describing token persistence or what state the result reports.

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, zero padding, and the primary purpose is front-loaded before the conditional side-effect 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 parameterless auth-check with a disclosed sign-in side effect and no output schema, the description is nearly complete. It could add what status values are returned or whether sign-in is interactive-blocking, but nothing essential for correct invocation 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?

The tool takes zero parameters and the schema is trivially complete, so there is nothing for the description to disambiguate. Baseline 4 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?

States a specific verb+resource: 'Check Microsoft 365 connection status.' The resource is unique among siblings (all of which are data-access tools), so an agent can distinguish it without ambiguity, though the description never names or contrasts any sibling 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?

Implicit guidance is present via the conditional 'If not connected, opens browser to sign in,' which tells the agent the side effect of calling while unauthenticated. However, it never states when to prefer this tool (e.g., before invoking ms_mail or ms_chat) or any exclusions, leaving usage 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is adding content-level detail — and it does, by naming the exact payload of each mode and noting the person mode narrows scope. It stops short of noting ordering, volume limits beyond 'count', or latency, so not a 5.

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?

Three sentences, front-loaded with the core value proposition, then the two modes, then the routing advice. No filler and no repetition of annotation or 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?

With no output schema, the description sensibly enumerates the returned sections, which is the key missing structured information. Minor gaps remain around result ordering and what happens when a section is empty, but nothing that would cause a misinvocation.

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 baseline is 3; the description goes beyond it by explaining that 'person' changes the whole behavior of the call rather than being a filter — 'who they are and your recent mail and chats involving them' — which is semantics the bare schema field doesn't convey.

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+resource ('assembles a catch-up') and enumerates exactly what gets assembled (meetings, unread mail, chats, tasks, transcripts), which cleanly separates it from the single-domain siblings ms_calendar, ms_mail, ms_chat and ms_tasks.

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 says 'Use this instead of calling four or five tools separately,' and gives the mode-selection rule: no arguments = the default daily catch-up, with person = a single-person catch-up. An agent knows both when to pick it and how to switch modes.

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 non-destructive, so the safety profile is covered. The description adds the default date-range behavior, which is genuine context, but says nothing about auth requirements, pagination, or coverage limits of the fetch.

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?

Three tight sentences, front-loaded with the core action, then the default behavior, then the alternate modes. No filler and every clause carries 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?

With no output schema, the description should carry more of the return-shape burden, but it names the available modes and the compact summarization behavior. It leaves the relationship between 'date' and the 'start'/'end' range pair implicit, a minor gap for a 6-param multi-mode tool.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema (including what 'compact' omits). The description only adds that date params default to today, which is minor meta-context; baseline 3 is correct.

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 ('Fetch the user's Microsoft 365 calendar events') and enumerates two secondary modes (list calendars, drill into an event). It is clear against generic tool names, but it never names the calendar-adjacent siblings (ms_schedule) it could be confused with, so it stops short of full sibling differentiation.

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?

Gives one useful usage rule ('Defaults to today if no date params given') and hints at alternate modes, which is more than nothing. However, it never states when to prefer this tool over ms_schedule or ms_brief, nor when to use which mode, leaving usage 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 readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful scope with 'recent' and conditional return behavior, but it omits the members-listing behavior and any pagination or rate-limit context.

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 tightly written sentences front-load the core purpose and then explain the conditional behavior without any wasted words. 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?

The description covers the primary list and message-retrieval modes, and the rich input schema fully documents the members parameter. It is complete enough for correct invocation, though explicitly mentioning the members sub-mode would make it stronger.

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 count, chat_id, and members. The description adds conditional meaning for chat_id but does not explain the members parameter or any other parameter details beyond what structured fields 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 states a specific verb ('Read') and resource ('Microsoft Teams chats'), making the tool's purpose clear. It does not explicitly differentiate itself from sibling tools like ms_teams or ms_mail, so it falls 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?

It clearly explains how to use the main variants: without chat_id it lists recent chats, and with chat_id it returns messages from that chat. It does not mention when to use an alternative sibling tool or address the members sub-mode, so it lacks full exclusion 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 and destructiveHint=false, so safety is covered. The description adds nothing beyond that: no mention of pagination, how 'shared' interacts with other params, or what item_id returns (download URL vs listing). With annotations carrying the safety profile, the description should still contribute operational detail and does not.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no waste. It could be slightly richer given five parameters, but it earns its place and is not padded.

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?

Five parameters, no required fields, no output schema, and no annotations beyond read-only hints. Ambiguity around which param combination is valid (e.g., search vs shared vs item_id) is left entirely unexplained, so an agent has to guess the mode-selection logic.

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 each parameter already has an explanation. The description's 'browse or search' hints at path/search modes but doesn't add syntax, mutual exclusivity, or precedence rules beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 gives a verb (browse or search) and resource (OneDrive files), which is clear enough on its own. But it doesn't distinguish this from sibling tools like ms_sharepoint or ms_search, which also surface file/content search. A minimally viable but non-differentiating statement.

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 on when to use this over siblings like ms_sharepoint or ms_search, and no mention of prerequisites such as a path or item_id. The description just states both modes exist without conditions for either.

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, openWorld and non-destructive, so the safety profile is covered. The description adds provenance (Graph item insights) and a default mode, but says nothing about authentication requirements, result freshness/latency, or how many insights Graph actually surfaces — modest added value over 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?

Three short sentences, front-loaded with what is returned before the use cases, and no filler or redundancy. Every sentence contributes to selecting or interpreting the tool.

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

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

With no output schema, the description should hint at the shape of returned document entries; it only says 'documents' without indicating whether titles, URLs, senders, or timestamps come back. For a two-parameter convenience tool this is adequate but leaves a real gap for an agent forming a response.

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 both parameters (kind, count) are already fully documented including enum meanings and the 1-50 default. The description only restates the default mode, adding no syntax or behavioral detail beyond the schema — 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?

The description states a specific resource (documents recently worked with or shared) and its data source (Microsoft Graph item insights), with concrete use-case phrasing ('what was I working on'). It implicitly distinguishes itself from filename-based retrieval ('without knowing a filename'), pointing away from ms_files/ms_search, though it never names those siblings.

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 this tool fits: recall-oriented questions where the filename is unknown, and it notes the default behavior ('Defaults to recently used'). No explicit exclusion or naming of alternative tools, so it falls short of the top band.

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/non-destructive, so safety is covered. The description adds useful behavioral detail beyond that: preview text vs. full body return shape, and which parameter combination triggers which mode. It does not mention pagination, volume caps, or auth prerequisites.

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 dense paragraph with the core action front-loaded and mode behaviors following. Every clause maps to a real parameter; no filler. Slightly packed but 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, open-world list/drill-down tool with no output schema, the description plus the fully documented schema covers the modes an agent needs to select and call correctly. Missing only edge behavior like pagination or result limits, which are minor 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%, so the schema already documents all 7 parameters including the folder default and the filter shortcuts. The description restates the same mode mappings rather than adding syntax or interaction rules beyond what the schema provides, 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?

The description states a specific verb and resource ('Read the user's recent emails from Microsoft 365') and separates the two operating modes (list vs. full-body drill-down). It does not, however, distinguish itself from siblings like ms_search or ms_chat, which an agent might reasonably confuse with mail 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?

It gives explicit conditional usage for nearly every parameter: no message_id lists previews, message_id returns full body, folders:true lists folders, attachments with message_id lists attachments, filter for quick filters. It stops short of stating when NOT to use this tool (e.g., vs. ms_search for cross-content search).

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, openWorld and non-destructive, so the safety profile is covered. The description adds behavior the annotations cannot: that 'user' returns manager and direct reports, and that 'groups' is scoped to the signed-in user's memberships. It omits auth/permission requirements and pagination behavior, keeping it out of 5 territory.

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 gives the purpose first, then the three modes in order of likely use. Every clause carries distinct information; there is no filler or repetition of the title.

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

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

With no output schema, the description usefully sketches what each mode returns (email resolution, person details plus manager/reports, memberships), and annotations cover the safety profile. Minor gaps remain: no guidance on what happens with zero parameters, no pagination note, and 'count' is unaddressed, but nothing blocks a correct call.

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 exceeds that by tying each parameter to an outcome and a purpose — 'search' exists specifically to resolve a name to the email address ms_schedule requires — which is meaning the schema text does not carry. 'count' is left to the schema, which is acceptable given its self-explanatory bounds.

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 ('Look people up in the organisation directory') and then enumerates the three distinct operations the tool supports (search, user, groups). This lets an agent distinguish it from siblings like ms_profile or ms_search without opening the schema.

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 routes the agent among the tool's three modes and names a concrete downstream consumer ('the input ms_schedule needs'), which is genuinely actionable. It stops short of stating when NOT to use this tool versus lookalike siblings such as ms_profile, so it is clear context rather than full when/when-not guidance.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive behavior, so the description carries a reduced burden. However, it adds no behavioral context at all beyond restating that this is a fetch: no auth/permission notes, no rate-limit or pagination hints, and no indication of what the profile payload contains.

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, front-loaded with the core action and followed by the scope-expansion option. Nothing is padded or repetitive.

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 zero-required-parameter, read-only call with rich annotations, the description covers the essentials. With no output schema present, it leaves what fields the profile actually returns (and what each include value adds) entirely unspecified, which is a modest 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?

Schema description coverage is 100% and the single parameter already enumerates "manager", "reports", "groups", "photo" in its own description. The description merely repeats that same list, adding no syntax or default-behavior detail, 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?

States a specific verb ("Fetch") and resource ("Microsoft 365 profile"), so the operation is unambiguous. It does not differentiate itself from the sibling ms_people, which is the likely overlap an agent would hesitate between.

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?

"Fetch the user's Microsoft 365 profile" implies the use case, and "Optionally include..." tells the agent it can widen scope to sub-resources. There is no explicit when-to-use/when-not guidance and no sibling (e.g. ms_people) is named as an 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 readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds meaningful return semantics: time slots are labeled free, busy, tentative, out of office, or working elsewhere. It does not discuss auth requirements, but openWorldHint covers that context.

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, front-loaded with the core purpose and followed by the return content. No filler; every phrase carries useful information for an agent.

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 query tool with rich annotations and a fully documented schema, the description is nearly complete. It explains the input shape and return statuses, though it could still note permission or auth expectations, which annotations only partially imply.

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 five parameters, including defaults and formats. The description adds only a general mention of email addresses and the time window, not syntax or behavior 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?

States a specific verb ('Check') and resource ('people's availability / free-busy status') with a clear time-window scope. It does not explicitly name or distinguish itself from sibling tools such as ms_calendar, but the free-busy focus is clear enough to separate it from general calendar 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?

The description gives no when-to-use guidance, no exclusions, and no alternatives. An agent can infer it is for availability checks, but there is no explicit routing advice versus ms_calendar or other scheduling-related 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=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety and operational profile. The description adds KQL syntax support, which is useful but doesn't go beyond basic query capabilities or discuss result behavior. With annotations carrying the core traits, a 3 is appropriate.

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?

Three sentences, front-loaded with the purpose, then usage guidance, then a concise feature note. No wasted words, and the structure prioritizes routing information first.

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

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

Given the tool's breadth and the absence of an output schema, the description covers the key selection logic and parameter capabilities. It could mention result limits or pagination behavior, but annotations handle safety and idempotency, so it is largely complete for an agent to invoke 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 description coverage is 100%, so the schema already documents all parameters (query, count, types). The description adds meaning by mentioning KQL support and providing a concrete example, which enriches the query parameter beyond the schema's generic description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb (search) and resource (Microsoft 365: mail, Teams chats, calendar events, OneDrive files, SharePoint), and it clearly distinguishes itself from the per-area sibling tools by naming ms_mail, ms_chat, and ms_files as alternatives.

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 provides explicit when-to-use guidance: 'use this when you do not already know where something lives' and directs to per-area tools when the location is known. This directly addresses tool selection among 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, idempotentHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds what the response contains (version, tools, runtime info), which is useful but modest beyond the structured data.

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, front-loaded with the return payload and closed with the use case. Every clause earns its place with no redundancy.

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

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

Zero parameters, no nested objects, and no output schema, and the description enumerates the main returned fields, so an agent has enough to call it. It stops just short of stating that it requires no arguments or auth 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?

The tool takes zero parameters, so there are no argument semantics for the description to explain. Baseline for a parameterless tool is 4.

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 ('Returns m365-mcp server metadata') and enumerates what comes back (version, available tools, runtime info). It is clearly distinguishable from the ms_* feature siblings, though it never explicitly says so.

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?

'Useful for debugging' is the only usage signal, which implies the scenario but gives no explicit when-to-use or when-not-to-use guidance. For a diagnostic-only tool with no competing alternative, this is minimally adequate rather than thorough.

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description usefully documents mode-dependent behavior and the default '*' search, but says nothing about result ordering, pagination, or permissions 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?

Two tightly written sentences with no filler, and the primary scope statement is front-loaded before the parameter-driven modes.

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, four-parameter tool with no output schema, the mode routing and site/list hierarchy are adequately explained. Minor gaps remain around result volume and pagination behavior, but nothing blocks 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?

Schema description coverage is 100%, so all four parameters are already documented in the schema, establishing a baseline of 3. The description reinforces the site_id/list_id dependency, which the schema also states, but adds no new syntax or format detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names three concrete operations (search sites, list lists, browse items) against a specific resource, so the agent knows exactly what the tool does. It does not differentiate itself from overlapping siblings such as ms_search or ms_files, which keeps it 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?

It gives explicit mode-selection guidance: no parameters searches all sites, site_id lists a site's lists, and site_id + list_id browses items. This is clear conditional routing, though it never names an alternative tool for the search 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 readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the default no-parameter mode returns task lists, and the planner mode is scoped to tasks assigned to the user, which the annotations cannot convey. It stops short of covering pagination limits or whether include_completed defaults are honored across modes.

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?

Three tightly packed sentences with no filler, and the core capability is front-loaded before the mode-by-mode breakdown. Every clause carries routing information an agent needs.

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 four optional parameters, 100% schema coverage, and no output schema, the description supplies the mode-selection logic that the flat schema cannot express. It is complete enough to call correctly, though it could note result caps or that completed tasks are excluded by default, which the schema mentions but the description does not reinforce.

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 count, list_id, planner, and include_completed individually. The description mostly restates the schema semantics for list_id and planner, adding only the implicit no-parameter default, 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?

The description opens with a specific verb and resource ("Read Microsoft To Do and Planner tasks") and then spells out the three distinct retrieval modes, so an agent knows exactly what this tool returns. It does not name any sibling tools, but the resource pairing with Planner/To Do is distinct enough within Microsoft 365 context signals to avoid confusion with ms_calendar or ms_schedule.

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 explicit conditional routing among its own modes (no parameters → task lists; list_id → tasks in that list; planner=true → Planner tasks). What it lacks is guidance on when to reach for this tool versus adjacent siblings such as ms_calendar or ms_schedule, so the usage context is clear but not exhaustive.

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/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond annotations: the progressive result set driven by which parameters are supplied. It omits the message_id/replies mode and the count cap, but the core behavioral contract is clear.

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, front-loaded with the core action and immediately followed by the mode table and the sibling distinction. No filler sentences; every clause carries routing or scoping 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 zero-required-parameter, read-only browse tool with strong annotations and a fully documented schema, the description covers selection and routing well. The one real gap is that the message_id thread-replies mode and the count limit are never mentioned, so an agent reading only the description would not know that capability exists.

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 four parameters are already documented, including the team_id/channel_id/message_id dependency chain. The description restates the team_id+channel_id combination but adds no syntax, ID format, or default/value detail beyond the schema, so it lands at the 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?

Uses a specific verb (Browse) and resource (Microsoft Teams), and explicitly enumerates the three operating modes. It also names the sibling it is not (ms_chat) and why, so an agent can route between them without opening either schema.

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?

States the exact conditions that select each mode: no params = joined teams, team_id = that team's channels, team_id+channel_id = recent messages. It also provides an explicit exclusion rule versus ms_chat for private/group chats, leaving nothing 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: ~3000-char previews in list mode and 10,000-char chunked retrieval with offset-based continuation. It omits auth/permission requirements and rate-limit behavior, so it is 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?

Three tight sentences with zero filler. The default mode (list with previews) is front-loaded before the drill-down behavior and pagination hint, matching how an agent would reason about calling it.

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 tool with rich annotations and a fully documented six-parameter schema, the description supplies the one thing the schema cannot express: the mode switch and chunking/pagination model. No output schema exists, but the description's explanation of preview and chunk sizes covers what to expect from returns.

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 goes beyond the schema by explaining the interaction semantics: transcript_id switches between list and drill-down mode and originates from a prior list call, while offset exists specifically to walk long transcripts. The date-range parameters (start/end/date) are never mentioned in the description and rely entirely on 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?

States a specific verb and resource ('Fetch meeting transcripts from Microsoft Teams') and clearly enumerates the two operating modes (list vs. content drill-down). It does not explicitly contrast itself with adjacent siblings such as ms_chat or ms_calendar, so an agent must infer the boundary, but the resource is specific enough that selection is unambiguous.

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

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

Gives explicit conditional guidance: omit transcript_id to list, supply it to drill into content, and use offset to continue through long transcripts. That is clear when-to-use routing within the tool. It stops short of naming alternatives or exclusions (e.g., when to prefer ms_chat or ms_search instead), which keeps it out of 5 territory.

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