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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuine context by enumerating what the call surfaces (active sign-in app, account, token validity), which is more than the annotations provide.

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

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

A single sentence with no filler, front-loaded with the primary output (which account/app is in use) followed by the token check.

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 must sketch return values — and it does, naming the three facts reported. A zero-parameter read tool needs little more, though noting the response shape or what happens on no active session would close the last 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 tool takes no parameters (0 required, 100% coverage on an empty schema), 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?

The description uses a concrete verb ("Show") plus the specific resources it reports — sign-in app, Microsoft 365 account, and token validity — so an agent grasps the diagnostic nature immediately. It stops short of naming the sibling tools it contrasts with (login, auto_login), which keeps it from 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?

"Whether a valid token is available" hints that this is a pre-flight check, but the description never states when to call it versus login/auto_login, nor any exclusions or ordering advice. Usage is implied rather than specified.

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=false and destructiveHint=false; the description adds genuine behavior context beyond them by explaining that enabling causes an expired session to open a browser sign-in and then resume the pending request. It does not say whether the setting persists across sessions or where it is stored, which is the remaining behavioral 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?

Two short sentences, zero waste, with the core action front-loaded and the default surfaced before the explanatory 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?

For a single-boolean toggle with annotations covering the safety profile and no output schema, this is largely sufficient. The only omission worth noting is persistence/auth requirements and the explicit effect of disabling.

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

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

Schema coverage is 0%, so the description must carry the meaning of 'enabled'. It does so reasonably by pairing 'on or off' with the concrete effect of 'on' and its default value, though it never states what 'off' means behaviorally (presumably failing instead of prompting).

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 action on a specific setting: 'Turn automatic sign-in on or off', with the default noted. The purpose is unambiguous, but it never contrasts itself with the related login or auth_status siblings, so an agent must infer how it differs from 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 explains what the on state does but gives no explicit guidance on when to call it versus login or auth_status, nor any precondition. Usage is only implied by the phrase 'automatic sign-in'.

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 only flag a non-read-only, open-world, non-destructive call; the description adds the important traits beyond that: a browser window and MFA interaction on the user's machine, tenant-default behavior ('organizations' = any work account) with the wrong-tenant risk, and that the app choice is persisted and cannot be changed from chat. It omits what a successful return looks like and what happens on failure/timeout.

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?

Front-loaded with the purpose, then a numbered decision list for the app choice, then small notes on timezone and persistence. It is somewhat long, but nearly every line carries actionable setup detail rather than 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?

Given four optional parameters, no output schema, and an interactive auth flow, the description covers the decision space, defaults, and post-configuration constraints well. What is missing is the relationship to auto_login/auth_status and any statement of what the call returns or how long it blocks.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: client_id is a GUID required for app='own', tenant is a tenant ID or verified domain (optional for 'microsoft', default 'organizations'), and timezone accepts 'auto' or an IANA zone with a documented default. Every one of the four parameters is given meaning the schema alone does not 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?

States a specific verb and resource ('Sign in to Microsoft 365') plus the mechanism ('Opens the system browser on this computer for sign-in/MFA'). It is clearly distinct from the planner/todo tools, but it never names its closest siblings (auto_login, auth_status), so an agent must infer the split between interactive and automatic sign-in.

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 instructs to ASK THE USER which app to use on first use or when switching, enumerates both options with their prerequisites, and says to omit app to reuse the saved choice. It also documents the escape hatch (terminal command / extension settings) for changing the app later, but does not say when to prefer auto_login or auth_status instead.

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=false, destructiveHint=false, and openWorldHint=true. The description adds no behavioral context beyond that: it does not state permission requirements, whether bucket names must be unique within a plan, or any side effects. For a mutation tool, this is thin even with annotations 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?

A single, front-loaded sentence with no wasted words. It is appropriately sized, though its brevity reflects under-specification rather than tight completeness.

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 two-parameter mutation tool with no output schema and zero schema description coverage, the description leaves critical gaps: parameter formats, name uniqueness, required permissions, and return behavior are all absent. An agent would have to guess at plan_ref 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?

Schema description coverage is 0%, so the description must compensate and does not. It does not clarify whether plan_ref expects a plan ID or a plan name, nor any constraints on the bucket name. The parameters are only described by their bare schema titles.

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: 'Create a bucket in a Planner plan.' An agent can distinguish this from planner_rename_bucket, planner_delete_bucket, and planner_list_buckets by the verb, but the description does not explicitly name or contrast with 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?

There is no explicit guidance on when to use this versus alternatives, nor any prerequisites. The only implied usage is that it creates a new bucket, which is derivable 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=false, destructiveHint=false and openWorldHint=true, so the mutation profile is covered. The description adds real context the annotations don't: buckets can be seeded at creation time, implying a multi-object write. It omits whether bucket creation is atomic with plan creation, what happens on partial failure, and what auth is required.

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 the resource and container front-loaded, then the optional bucket seeding with a concrete example. No filler, no redundancy with 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?

There is no output schema, so the description should say what comes back — critically, whether the created plan's ID is returned, which the agent needs to chain into planner_create_bucket or planner_create_task. Auth/permission requirements and partial-failure behavior are also unaddressed for a write tool with an openWorld hint.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does partially: it explains what 'buckets' means and gives a concrete example array, and it implies group_id is a Microsoft 365 group identifier. However it does not state that group_id is a GUID or that title is required, leaving two of three parameters under-specified.

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 specific verb ('Create') and a precisely named resource ('Planner plan (project)'), plus the container it lives in ('Microsoft 365 group'). The parenthetical 'project' disambiguates the Microsoft term. It stops short of naming a sibling, but the resource distinction from planner_create_bucket / planner_create_task is obvious from the noun alone.

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 never says when to use this versus planner_list_plans or planner_create_bucket, nor any prerequisite such as needing an existing group or the right permissions. The only implicit guidance is that a group must already exist, inferred from 'in a Microsoft 365 group'.

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=false, destructiveHint=false, and openWorldHint=true, so the write-and-non-destructive profile is covered. The description adds nothing behavioral beyond that: no mention of required permissions, what the tool returns, whether creation is idempotent, or side effects like notifications to assignees. For an 11-parameter mutation tool, this leaves real gaps.

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 short and front-loads the core action ('Create a Planner task') before listing format hints. Every clause carries information and nothing is padded. It is efficient, if a little telegraphic in the trailing format notes.

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 11 parameters and no output schema, the description should document more of the input surface and the return behavior. It covers only assignee/label/date formats and omits priority/progress enums, checklist structure, bucket_ref, and what a successful creation yields, which is insufficient for a tool of this 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 coverage is 0%, so the description must compensate, but it only clarifies three parameters: assignees (me / object ID / email), labels (names defined on the plan), and date format (YYYY-MM-DD local). Eight parameters — plan_ref, bucket_ref, priority, progress, checklist, description, title, start — are undocumented in both schema and description. Partial compensation at best.

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+resource: 'Create a Planner task'. This distinguishes it from planner_update_task and planner_delete_task by action, and from todo_create_task by resource (Planner vs To Do). It doesn't explicitly name those siblings, but the verb+noun makes the operation 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?

There is no guidance on when to use this versus todo_create_task, or when a task belongs in a plan/bucket versus the To Do list. No prerequisites are stated (e.g., that plan_ref must resolve to an existing plan, or that a bucket must exist first). The agent must infer usage entirely.

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 flag destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description still adds real value by disclosing the cascade effect ('ALL tasks in it') and the permanence, which annotations alone do not convey. It stops short of saying whether the plan itself survives or how partial failures behave.

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, the destructive scope front-loaded and the safety instruction second. No filler.

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

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

For a destructive, irreversible mutation the cascade warning and confirm-first instruction are the most important content and are present. With no output schema and zero parameter documentation, though, the definition leaves a real gap around how to supply and validate the two required refs before committing an irreversible 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 0% — neither plan_ref nor bucket_ref is documented anywhere. The description does not explain what these refs are or where to obtain them (presumably planner_list_plans / planner_list_buckets), so the agent is left to infer both 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?

States a specific verb and resource ('Permanently delete a bucket') and adds the critical scope detail that all contained tasks go with it. It implicitly distinguishes itself from the sibling delete tools (planner_delete_plan, planner_delete_task) via the resource noun, though it never names them 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?

'Confirm with the user first' gives one concrete precondition for invocation. However, there is no guidance on when to prefer alternatives (renaming/emptying a bucket, deleting the plan instead) or on how to recover from a mistaken call.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description isn't carrying the safety burden alone. What it adds is genuinely new: the deletion is permanent (no undo/trash) and it cascades to all buckets and tasks, which is exactly the blast-radius information an agent needs before confirming.

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, zero waste, with the destructive scope front-loaded ahead of the confirmation directive. Nothing repeated from the title or annotations.

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

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

For a destructive, cascade-deleting tool the description covers impact and confirmation well, and annotations cover the safety profile. The remaining hole is the one input: plan_ref is undefined everywhere, so the description is not fully sufficient to invoke the tool 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?

The single required parameter, plan_ref, has 0% schema description coverage — no type detail, format, or example — and the description says nothing about it either. The agent cannot tell whether plan_ref is an opaque ID, a name, or a path, which matters a lot for a permanent destructive operation.

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 ('Permanently delete a Planner plan') plus the cascade scope ('with ALL its buckets and tasks'). The cascade detail is what separates it from planner_delete_bucket and planner_delete_task, so an agent can pick the right deletion tool without opening 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?

Gives a concrete procedural prerequisite — 'Confirm with the user first' — which is the key gating instruction for a destructive tool. It does not explicitly name alternatives or when-not-to-use, but the resource is unambiguous enough that routing is implied by the sibling names.

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

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

Annotations already disclose destructiveHint=true and readOnlyHint=false, so the safety profile is partially covered. The description adds value by emphasizing that deletion is permanent and by requiring user confirmation, though it does not describe cascading effects or permissions.

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

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

The description is two short sentences with zero wasted language. The permanence warning is front-loaded, and the confirmation instruction follows 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 one-parameter destructive action whose annotations already declare destructive and open-world behavior, the description covers the essential context: permanence and user confirmation. It leaves minor gaps around task ID format and side effects, but no output schema is present and the tool is structurally simple.

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 single parameter task_id has 0% schema description coverage, and the description does not explain its format, source, or constraints. Mentioning a Planner task implies the ID type only weakly and does not compensate for the missing schema documentation.

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: permanently delete a Planner task. It distinguishes the tool from siblings such as planner_delete_plan, planner_delete_bucket, and todo_delete_task by naming the Planner task resource 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?

The description gives one explicit procedural guideline: confirm with the user first. It does not explain when to choose this tool over alternatives such as planner_update_task or when deletion should be avoided, so usage guidance is only minimally viable.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful return-content context ("including description and checklist") but does not mention permissions, missing-task behavior, or whether checklist/description may be absent.

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 communicates the core action and the notable returned fields efficiently.

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 read tool with annotations and no output schema, the description is minimally adequate. However, it omits task_id semantics and does not clarify use relative to list/get alternatives, which are the main gaps an agent would need to resolve.

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

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

Schema description coverage is 0%, so the single required parameter task_id is undocumented in the schema. The description does not compensate by explaining task_id format, where to obtain it, or any constraints, leaving only the parameter name to carry meaning.

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 Planner task," and adds what is returned ("description and checklist"). It implicitly distinguishes Planner tasks from Todo tasks, but does not explicitly differentiate this retrieval tool from siblings such as planner_list_tasks or todo_get_task.

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 explicit guidance on when to use this tool versus planner_list_tasks, planner_my_tasks, or todo_get_task. The word "Get" implies single-task retrieval, but no alternatives or exclusions 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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that buckets are columns within a Planner plan, but does not mention pagination, return format, auth requirements, or rate limits beyond what annotations provide.

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

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

The description is a single front-loaded sentence that is efficient and easy to scan. It is appropriately sized for a simple list tool, though it could include slightly more context without becoming verbose.

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 and has an output schema, so return values need not be described. However, the description omits how to obtain plan_ref and does not clarify pagination or ordering, leaving gaps for an agent with no schema description coverage.

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

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

Schema description coverage is 0%, and the single required parameter plan_ref has no schema description. The description implies plan_ref identifies the Planner plan but gives no format, source, or constraint information to compensate for the schema gap.

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

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

The description states a specific verb ('List') and resource ('buckets (columns) in a Planner plan'), making clear it is a read operation on bucket collections. It distinguishes the resource from planner_list_plans and planner_list_tasks, though it does not explicitly name alternatives or scope exclusions.

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 sibling tools such as planner_list_plans, planner_list_tasks, or planner_create_bucket. Usage is only implied by the tool name and description, with no explicit context 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 readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds the non-obvious operational constraint (GroupMember.Read.All required) and the consequence of lacking it, which goes beyond structured fields. Pagination/truncation behavior on large group lists is not mentioned, keeping it short of 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?

Two sentences, zero filler. The purpose is front-loaded and the permission caveat with its alternative follows 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 zero-parameter read-only list tool with an output schema, everything an agent needs is present: what it returns, why to call it, and what to do if the permission is missing. No behavioral gaps remain.

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 is nothing to disambiguate; baseline 4 applies. The description correctly avoids restating the empty 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 ('List Microsoft 365 groups the user belongs to') and explains the purpose of the result ('needed as the container when creating a plan'). This makes it clearly distinguishable from the sibling planner_list_plans, which returns plans rather than group containers.

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 states when to use it (obtaining the group container for plan creation) and gives a named fallback path: if the GroupMember.Read.All permission is unavailable, take group IDs from planner_list_plans. Both the selection and the exclusion are spelled out.

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, non-destructive, openWorld). The description adds real behavioral value by disclosing the visibility scope (only plans shared with the caller) and that group IDs accompany the results, but says nothing about pagination or result size limits.

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

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

A single, front-loaded sentence with no filler. The scope qualifier comes before the return detail, which is the right order.

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-param list tool with an output schema covering return values, the description supplies purpose, visibility scope, and a hint at returned fields. Only pagination/ordering behavior is left unstated.

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 is no parameter semantics to explain; the baseline of 4 applies. The description correctly implies no filtering inputs are required.

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 (List) and resource (Planner plans/projects), plus the scope 'shared with the signed-in user'. The resource is inherently distinct from siblings like planner_list_buckets and planner_my_tasks, though no sibling is named 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?

Usage is only implied: when you need plans, call this. There is no statement of when to prefer planner_list_my_groups vs planner_my_tasks, or any prerequisite such as being signed in (beyond the 'signed-in user' phrase).

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 read-only, non-destructive, open-world profile, so the bar is low, but the description adds no behavioral context at all — no mention of pagination, result volume, permission requirements, or that completed tasks are hidden unless include_completed is set.

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-formed sentence with the resource front-loaded and zero filler. It is structurally sound, though its brevity is partly the cause of the semantic gaps noted above.

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?

An output schema exists, so return values need not be described, but with 4 parameters at 0% schema coverage and a near-identical sibling, the description leaves too much for the agent to infer about the required plan_ref and filter defaults.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it only names three filter axes collectively and never explains plan_ref (required — is it an ID or a display name?) or how bucket_ref and assigned_to_me interact.

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 tasks in a Planner plan') plus the optional narrowing dimensions, so an agent immediately knows what it returns. It does not, however, distinguish itself from the sibling planner_my_tasks, which overlaps with the assigned_to_me filter.

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 by the phrase 'optionally filtered by bucket, completion and assignment,' which tells the agent when to pass filters, but there is no explicit when-to-use guidance or routing to the alternative planner_my_tasks.

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, openWorldHint=true, so the safety profile is covered. The description adds useful cross-plan/signed-in-user scoping, but says nothing about the default exclusion of completed tasks or result volume/pagination behavior.

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

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

One sentence, front-loaded with the verb and resource, with the scope qualifier in the same clause. Nothing extraneous and nothing to trim.

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 tool with annotations and an output schema, the description covers identity, scope, and safety adequately. The only real gap is the unmentioned include_completed filter, which is small but agent-relevant.

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 single parameter include_completed has 0% schema description coverage and is never mentioned in the description. Its default of false (completed tasks hidden by default) is a meaningful behavioral consequence the agent must discover from the schema alone, and the description does not compensate.

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 Planner tasks') plus precise scope ('assigned to the signed-in user across all plans'), which implicitly separates it from planner_list_tasks and planner_get_task. It never names a sibling explicitly, so it stops short of the top mark.

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 by the phrasing 'assigned to the signed-in user' — an agent can infer this is the 'what's on my plate' query. There is no explicit when-to-use guidance, no statement of when to prefer planner_list_tasks, and no mention of the include_completed filter as a selection consideration.

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=false, destructiveHint=false, and openWorldHint=true, so the mutation nature is covered structurally. The description adds nothing beyond that: it doesn't say whether the old name is freed, whether name collisions are rejected, whether tasks in the bucket are affected, or that the change is visible plan-wide.

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 short, front-loaded sentence with no filler. However, the brevity here reflects under-specification rather than efficient communication; nothing beyond the bare action is conveyed.

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 mutating tool with three undocumented required parameters and no output schema, the description is too thin. An agent can call it, but cannot confidently resolve what the refs should be or what the effect of the rename will be.

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

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

Schema description coverage is 0%, so the description carries the full burden — yet it explains none of the three required parameters. It's unclear whether plan_ref and bucket_ref are IDs, names, or opaque tokens, or whether new_name accepts arbitrary strings; only 'new_name' is loosely implied by the tool name.

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 (rename) and resource (a bucket within a Planner plan), which distinguishes it from planner_rename_plan and todo_rename_list by target object. Clear and unambiguous, though it doesn't explicitly name those siblings 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?

No guidance on when to use this versus planner_rename_plan or the todo equivalents, and no prerequisites stated (e.g., does the bucket need to exist, are permissions or a plan owner required?). The agent must infer all usage context from the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful detail that plan_ref may be an exact title, hinting at lookup behavior, but says nothing about duplicate-title ambiguity, permissions, or what is returned after the rename.

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 action and followed immediately by the one clarifying detail. No waste.

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

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

For a simple two-parameter rename tool with annotations covering safety and no output schema, the description covers the essentials. The remaining gap is edge-case behavior for title-based lookup, which is minor but would help 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 0%, so the description must compensate, and it does explain plan_ref as 'plan ID or exact title' — the one non-obvious parameter. new_title is self-explanatory, but no constraints (length, uniqueness, empty string) are given.

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 ('Rename a Planner plan'), which is unambiguous and clearly distinct from sibling mutations like planner_delete_plan or planner_rename_bucket. It does not explicitly name or contrast with siblings, but the name and verb make selection straightforward.

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 versus planner_list_plans (to find the plan) or planner_rename_bucket, and no prerequisites such as needing the plan to exist or permissions. Usage is only implied by the verb.

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 is not read-only, not destructive, and open-world. The description adds valuable behavioral detail beyond that: only supplied fields change, empty strings clear due/start, bucket_ref moves within the same plan, labels replace rather than append, check_items tick existing items, and progress='completed' completes the task. It does not cover auth requirements, side effects like notifications, or return shape, so it is strong but 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?

The description is front-loaded with the core operation and partial-update contract, then uses short sentences for field-specific behavior. Every sentence earns its place, and there is no redundant restatement of the tool name or 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?

For a 13-parameter mutation tool with no output schema and 0% schema description coverage, the description covers key field semantics but leaves several parameters and the expected response unaddressed. It is adequate for the most important behaviors but not complete enough to eliminate ambiguity across the full parameter set.

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

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

Schema description coverage is 0% across 13 parameters, so the description must carry the full explanatory burden. It explains due, start, bucket_ref, labels, check_items, and progress well, but leaves title, description, priority, task_id, add_assignees, remove_assignees, and add_checklist unexplained. The distinction between check_items and add_checklist is especially important and is not addressed.

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: 'Update a Planner task.' That cleanly separates it from create, delete, and get siblings without ambiguity. It stops short of explicitly naming a sibling or scoping when this should be chosen over them, so it earns a 4 rather than 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?

Usage is implied by 'Update a Planner task' and 'Only supplied fields change,' which tells the agent this is a partial-update operation on an existing task. However, there is no explicit when-to-use guidance, no mention of prerequisites such as task existence, and no routing to alternatives like planner_create_task or planner_get_task.

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=false, destructiveHint=false, openWorldHint=true, so the agent knows this is a non-destructive write to an external system. The description adds nothing beyond that: it doesn't say whether the item is appended at the end of the checklist, whether ordering matters, whether duplicates are allowed, what happens if task_id is invalid, or what is returned.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity comes partly from omitting information rather than from tightening prose.

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?

A three-required-parameter mutation tool with zero schema description coverage, no output schema, and a bare one-line description leaves real gaps: ID formats, append semantics, error behavior, and return value are all unstated. Annotations cover only the safety profile.

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

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

Schema description coverage is 0% and none of the three required parameters (list_ref, task_id, text) are described in the schema. The description only implies that text is the item content and that a task is targeted; it never explains the list_ref vs task_id distinction, accepted ID formats, or limits on 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?

States a specific verb ("Add") and resource ("checklist (sub-step) item to a To Do task"), and the parenthetical clarifies what a checklist item is. This distinguishes it implicitly from todo_update_checklist_item and todo_delete_checklist_item in the sibling list, though it never names 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?

No guidance on when to use this versus todo_update_task, todo_update_checklist_item, or todo_create_task. An agent must infer prerequisites (an existing task must exist, list_ref/task_id must resolve) and there are no exclusions or alternatives offered.

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=false, destructiveHint=false and openWorldHint=true, so the safety profile is known. The description adds nothing beyond that: no note on whether list names must be unique, what happens on duplicate names, whether the caller is the owner, or what the newly created list looks like.

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

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

One short sentence with the verb and resource front-loaded and no filler. It is efficient, though its brevity is partly under-specification rather than pure concision.

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 create tool with annotations covering safety, this covers the essentials of what it does. It is missing duplicate-name behavior and any hint of the return value (e.g., new list id), which matters since no output schema 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?

The single required parameter 'name' has zero schema description coverage, and the description only implies it is the list name. No constraints (length, uniqueness, allowed characters) or format guidance are supplied anywhere.

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 ('Create a new Microsoft To Do task list') and clarifies terminology with '(project)'. It does not explicitly distinguish itself from similarly named siblings like planner_create_plan or todo_rename_list, so an agent must infer the product boundary.

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 versus planner_create_plan (create a Planner plan) or the rename/delete list siblings. The usage is only implied by the verb 'Create' in the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is carried. The description adds genuinely useful context the annotations don't cover: accepted date formats and local-time interpretation, plus the fact that checklist values become sub-steps. It omits what the call returns and whether a list_ref must already exist.

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?

Front-loaded with the core verb+resource, then two compact clarifications, with zero filler. The telegraphic second sentence ('checklist adds sub-steps.') is terse to the point of mild ambiguity but still earns its 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?

For a 9-parameter creation tool with zero schema descriptions and no output schema, the description addresses only the date and checklist concerns. The required list_ref is undefined and six optional parameters have no stated meaning, which is not enough for an agent to call this 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 0% across 9 parameters, so the description must compensate and largely does not. It clarifies formats for the date-like fields (due/start) and the semantics of checklist, but leaves list_ref (the ambiguous required one—name or id?), notes, reminder, categories and importance entirely unexplained.

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 ('Create a task in a To Do list'), which is unambiguous on its own. However, the sibling set contains planner_create_task, a near-identical operation on a different surface, and the description does nothing to distinguish the two.

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 versus planner_create_task or todo_create_list, and no mention of auth or the prerequisite of knowing a valid list reference. The only hinted rule is date formatting, which is a parameter convention rather than usage guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds the confirmation-before-deletion requirement, which is real added value, but says nothing about irreversibility, whether the parent task is affected, or what is returned.

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 zero filler, and the action is front-loaded ahead of the safety instruction. Nothing could be removed without losing 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 destructive three-identifier mutation with no output schema and no parameter documentation, the description is too thin. An agent still cannot determine the format of list_ref or item_id, or how to recover the identifiers needed 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 description coverage is 0% and all three parameters (list_ref, task_id, item_id) are undocumented bare strings. The description adds no meaning whatsoever about what these identifiers are, their formats, or where they come from, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource: "Delete a checklist item from a To Do task." This distinguishes it implicitly from todo_delete_task (whole task) and todo_update_checklist_item, though it never names 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?

"Confirm with the user first" gives a procedural precondition for invocation, which is genuinely useful. However, there is no guidance on when to choose this over todo_update_checklist_item (e.g. clearing vs removing) or what to do if the item is the last one.

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 mark this as destructive, but the description adds critical behavior beyond them: deletion is permanent, all contained tasks are also deleted, user confirmation is required, and the default list is protected. This is exactly the context an agent needs before invoking a destructive cascade.

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 compact sentences with the destructive scope and safety precondition front-loaded. Every sentence adds actionable information without waste.

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 destructive tool with annotations covering safety and no output schema, the description explains the important behavior: permanence, cascading deletion, confirmation, and the default-list exception. The main remaining gap is how list_ref identifies the list, which is a parameter-level omission rather than an overall behavioral omission.

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 one required parameter, list_ref, with 0% description coverage, and the tool description does not explain whether list_ref is a name, ID, or reference format. The mention of the default 'Tasks' list provides slight context but does not compensate for the missing parameter semantics.

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: permanently delete a To Do list. It also clarifies cascading scope by stating that all tasks in the list are deleted, which distinguishes it from todo_delete_task.

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 usage guidance: confirm with the user first, and do not use it on the default 'Tasks' list. It does not name an alternative tool, but the when-to-use and when-not-to-use conditions are explicit.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety bar is low, but the description still adds real value: 'Permanently' signals irreversibility and the confirmation requirement is an operational constraint absent from the structured data. It stops short of saying what collateral is removed (checklist items, attachments) or whether auth/sign-in is required.

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 filler, with the destructive nature and the confirmation gate front-loaded. Nothing to cut.

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?

Annotations carry the safety profile and there is no output schema to explain, so the main remaining need is identifier semantics and deletion scope. Both are missing at 0% schema coverage, making this only minimally adequate for an irreversible operation.

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

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

Schema description coverage is 0% and both parameters (list_ref, task_id) are required. The description says nothing about what a list_ref is (id vs display name), nor that task_id must belong to that list, leaving the agent to guess at identifiers.

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?

Specific verb plus resource ('Permanently delete a To Do task') tells an agent exactly what happens. The 'To Do' naming implicitly separates it from the Planner siblings (planner_delete_task), but the description itself never draws that distinction 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?

The only guidance is 'Confirm with the user first', which is a safety instruction rather than a when-to-use rule. It does not say when to delete versus archive/update, nor redirect to a sibling such as todo_update_task when the user may only want to close the 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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds genuine value by disclosing that notes and checklist items are included in the response — information not in any structured field. However, it says nothing about error behavior for missing tasks or auth requirements implied by both list_ref and task_id.

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 efficient sentence with zero padding, and the resource is front-loaded. It is appropriately short for a simple getter, though the brevity comes at the cost of leaving the two required parameters unexplained.

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

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

For a tool with two required, fully undocumented parameters and no output schema, the description should at minimum clarify how list_ref and task_id combine to identify a task. It discloses the returned content but leaves parameter meaning entirely unaddressed, which is a real gap given 0% schema coverage.

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

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

Schema description coverage is 0%, so the definition carries the full burden of explaining 'task_id' and 'list_ref', and the description says nothing about either. An agent cannot tell from this text whether list_ref is a list ID, a display name, or a path, nor whether task_id is global or list-scoped. The only semantic hint is that both are required together to identify the task.

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 ('Get one To Do task') and adds scope detail ('with notes and checklist items'), which distinguishes it from todo_list_tasks and planner_get_task. It doesn't explicitly name the sibling it replaces, but the singular 'one' plus the returned sub-resources makes the intent 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?

Implied usage only: 'Get one' suggests use when a single known task is needed rather than enumerating, which nudges the agent toward todo_list_tasks for discovery. There is no explicit when-to-use statement, no note that both list_ref and task_id are required to locate the task, and no pointer to todo_update_task once the task is fetched.

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, and openWorldHint=true, so the safety profile is covered. The description adds only that results are scoped to the signed-in user; it says nothing about ordering, pagination, or empty-result behavior, though the output schema covers the return shape.

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 redundant restatement of the tool name or annotations. Nothing could be removed without losing 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?

With no input parameters, an output schema present, and annotations covering the safety profile, the description is close to complete. A minor gap is the absence of any note on ordering or result limits, which an agent may care about when listing.

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, which is the baseline-4 case. There are no parameter semantics to explain, and the description correctly refrains from inventing any.

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 all Microsoft To Do task lists (projects)') and scopes it to the signed-in user, which distinguishes it from the Planner listing siblings. It does not explicitly name the nearby sibling todo_list_tasks, so differentiation relies on the agent noticing the resource noun.

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

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

The phrase 'for the signed-in user' implies usage context, and the tool takes no parameters so there is little to misconfigure. However, there is no explicit statement about when to use this versus planner_list_plans or todo_list_tasks, leaving the choice to be inferred from names.

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, openWorldHint=true, so the safety profile is covered without the description. The description adds no behavioral context at all — notably it never says that completed tasks are excluded by default (include_completed=false) or that results are capped at 100 items, both of which materially affect what the agent sees.

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 purpose, no filler. It is efficiently sized, though the second sentence is purely parameter gloss rather than anything about 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?

An output schema exists, so return values need no explanation, and the single required parameter is documented. Still, default filtering of completed tasks and the item cap are undocumented in both the schema and the description, which for a list tool is a meaningful gap an agent cannot recover from structured fields alone.

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

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

Schema description coverage is 0%, so the description carries the burden; it usefully clarifies the required list_ref as "list ID or exact name" with an example, which is the non-obvious parameter. However, max_items and include_completed get no explanation of semantics such as defaults or truncation behavior, so compensation is only partial.

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 specific verb+resource ("List tasks in a To Do list"), which is clearer than the bare tool name. The product qualifier "To Do" implicitly separates it from planner_list_tasks, but the sibling is never named, so differentiation is left to inference.

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 only implied: it's the read-only listing tool for To Do lists, and the description explains how to supply list_ref. There is no statement about when to use this versus planner_list_tasks, todo_get_task, or todo_list_lists, and no prerequisites 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?

Goes well beyond the annotations by disclosing the copy-then-delete implementation, the exact fields preserved (title, notes, dates, importance, status, categories, checklist), and the side effect that the task gets a new ID. Missing only failure behavior (e.g., what happens if the target list doesn't exist or the task is not found).

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 compact sentences, zero filler, with the identifying operation front-loaded and the important side effects immediately after. Nothing repeats the name or annotations.

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 copy/delete semantics and new-ID side effect make the tool callable for the happy path, but with no output schema, no parameter documentation, and no error or precondition information, an agent cannot tell what to expect on failure or how to construct valid list references.

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

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

Schema description coverage is 0% for three required parameters, and the description never explains from_list_ref, to_list_ref, or task_id — not even whether refs are IDs or names, nor why the source list must be supplied. The description must compensate here and largely does not.

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 (move a task to another To Do list) and adds the crucial mechanism in parentheses: copy fields then delete the original. This makes it clearly distinct from todo_update_task, todo_delete_task, and todo_create_task without the agent opening any 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?

The phrase 'Move a task to another To Do list' implies the use case, and the copy-then-delete note hints at why one would choose this over recreating the task manually. However, no explicit when-to-use vs. todo_update_task (which might also change lists) or when-not guidance 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 disclose readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is known. The description adds nothing beyond that: it says nothing about permission requirements, what happens if list_ref matches nothing, or how ambiguity between identically named lists is resolved.

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-loading the action and then the key parameter nuance. Every word earns its place with no 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 two-parameter mutation with no output schema and zero schema coverage, the description covers the purpose and the ambiguous parameter but leaves error behavior, permission needs, and name-collision handling unaddressed. Adequate to invoke, not fully complete.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It does clarify the non-obvious list_ref ('list ID or its exact name'), but says nothing about new_name beyond what the title implies and gives no guidance on exact-name matching rules or name collisions.

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 ('Rename a To Do list') and the 'To Do' qualifier separates it from the planner_rename_plan and planner_rename_bucket siblings. An agent can identify exactly what this tool does 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?

Gives no when-to-use context, no prerequisites, no exclusions, and never mentions the neighboring rename or list-management tools (todo_create_list, todo_delete_list, planner_rename_plan). Usage is left entirely implicit from the tool name.

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

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

Annotations already declare this is a non-read-only, non-destructive, open-world mutation, so the safety profile is covered. The description adds the useful partial-update semantics ('Rename and/or tick/untick' suggests fields are optional), but it omits permission requirements, whether unmentioned fields are preserved, error behavior, or response shape for a mutation 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?

One front-loaded sentence with no filler. It states the operation and scope efficiently.

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?

A five-parameter mutation tool with 0% schema description coverage and no output schema needs more than one line. The description does not explain the required identifiers, how to obtain item_id, or what a successful update returns, so an agent would need to infer too much.

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

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

Schema description coverage is 0%, so the description must explain the five parameters. It only hints at two operations (rename via text, tick/untick via checked) and never mentions list_ref, task_id, or item_id, nor which parameters are required. This leaves the agent dependent on bare schema names for addressing the target item.

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 ('Rename and/or tick/untick') and resource ('checklist item on a To Do task'), which is enough for an agent to identify the operation. It does not name the sibling tools it competes with (todo_add_checklist_item, todo_delete_checklist_item), so sibling differentiation is only 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?

There is no explicit guidance on when to use this tool versus todo_add_checklist_item or todo_delete_checklist_item, nor any prerequisites or restrictions. The 'and/or' phrasing implies partial updates are allowed, but that is inference rather than stated 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=false, destructiveHint=false and openWorldHint=true, so the safety profile is known. The description adds genuinely non-obvious behavior: this is a partial/PATCH-style update where omitted fields are preserved, and dates are cleared by passing an empty string rather than being left out. It still doesn't say what the call returns or whether clearing a date is reversible.

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, zero filler, and the most load-bearing rule ('Only supplied fields change') is front-loaded immediately after the purpose statement. Each sentence adds distinct 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 10-parameter mutation tool with no output schema and zero schema descriptions, the description covers patch semantics and date clearing but leaves identifier semantics and most field behavior unaddressed. An agent could call it correctly for status/date changes but would be guessing on identifiers and categories.

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

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

Schema description coverage is 0% for 10 parameters, so the description must compensate. It resolves the two most dangerous ambiguities — null/omitted means 'unchanged' and empty string means 'clear' for due/start/reminder — but says nothing about task_id vs list_ref, categories, importance, notes, or the other three status enum values, leaving half the surface undocumented.

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

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

States a specific verb and resource ('Update a To Do task') that clearly separates it from todo_create_task and todo_get_task, and the 'To Do' qualifier implicitly separates it from planner_update_task. It does not explicitly address the nearest sibling, todo_move_task, or say when a move should be preferred over an update.

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 operational rules for *how* to use fields (only supplied fields change, empty string clears a date, status='completed' vs 'notStarted'), which is real usage guidance. It gives no guidance on *when* to choose this tool over alternatives such as todo_move_task or planner_update_task, so usage is only implied at the selection level.

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