Microsoft 365 MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.143.0
Disambiguation2/5
With 188 tools, there is substantial overlap and near-duplicates. For example, calendar listing has seven tools (list-calendar-events, get-calendar-view, get-specific-calendar-view, list-specific-calendar-events, list-calendar-view-delta, list-calendar-events-delta, list-calendar-event-instances), and mail has many similar create/forward/reply variants. Agents will struggle to pick the correct tool without carefully reading the tips.
Naming Consistency4/5
Tool names predominantly follow a hyphenated verb-noun pattern (list-, get-, create-, update-, delete-). There are minor deviations like 'graph-batch' and 'parse-teams-url', but the overall convention is predictable and readable, making it easy to infer the action.
Tool Count1/5
188 tools is extremely excessive for an MCP server, even one covering the breadth of Microsoft 365. This overwhelms agent context windows and increases selection error rates. A well-scoped server would consolidate related operations or expose only high-level workflows.
Completeness3/5
The server covers many Microsoft 365 domains extensively (mail, calendar, contacts, OneDrive, Excel, To Do, Planner, OneNote, subscriptions). However, there are notable gaps such as missing delete-planner-task and no update-onenote-page, leaving some resources without full lifecycle coverage.
Average 3.9/5 across 155 of 188 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 95 of 96 community issues answered or closed in the last 6 months
- 91 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply says 'Sort' without disclosing side effects, reversibility, or how the range is modified. While annotations do indicate destructiveHint: true and readOnlyHint: false, the description itself contributes no additional behavioral context, and the agent is left to infer what happens to the data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It consists of a single sentence that merely repeats the tool name, lacking any meaningful structure or additional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, a required nested body, and destructive implications, the one-sentence description is grossly inadequate. It fails to explain what sort operation is performed, what the output looks like, or how to construct the request, making it nearly impossible for an agent to invoke correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 86%, the core 'body' parameter is required but its schema only includes an optional 'id' with additionalProperties: true, leaving the actual sort configuration unspecified. The description does not clarify what should go in the body, so the agent cannot determine how to specify sort keys, order, or range structure from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sort an Excel range' is essentially a verbatim restatement of the tool name and provides no additional specification of what sorting entails (e.g., keys, order, orientation). It does identify a verb and resource but adds no distinguishing details beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like update-excel-range or insert-excel-range, nor any context about prerequisites (e.g., whether the range must exist) or when it is appropriate to sort.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. However, the description adds no behavioral context beyond the annotations—it does not describe return format, pagination behavior, or any side effects, missing the opportunity to enrich the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. The single sentence 'Get an Excel range.' does not earn its place because it merely repeats the tool name without providing any useful information, making it an empty filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and only basic annotations, the description is critically incomplete. It does not explain what an 'Excel range' is, how to format the address, what data is returned, or how pagination/optional parameters behave. The agent would have to rely entirely on the schema and guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with every parameter (driveId, driveItemId, workbookWorksheetId, address, fetchAllPages, includeHeaders, excludeResponse) having a clear description. The tool description itself adds nothing to parameter semantics, but the schema fully compensates, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get an Excel range.' is a tautology that restates the tool name without adding any new information. It does not distinguish this tool from siblings like get-excel-table or get-excel-used-range, which also operate on Excel data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention typical use cases, prerequisites (e.g., knowing the worksheet or address), or which sibling tools should be preferred in different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The truncated description adds only a hint about getting contacts in another user's folder but does not complete the behavioral details, adding minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is severely truncated mid-sentence, making it incomplete and not concise. It fails to convey a complete thought, which undermines its usefulness. Conciseness requires completeness, which is absent here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return values or behavior. Instead, it is truncated and provides insufficient context for a tool with 6 parameters and complex features like expand and fetchAllPages. The description is not complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 6 parameters with descriptions, achieving 100% coverage. The tool description does not add any new parameter information beyond the schema, so it meets the baseline without improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts by stating 'Retrieve the properties and relationships of a contact object', which clearly indicates the verb and resource. However, it then mentions 'two scenarios' without completing the thought, leaving ambiguity about the full purpose. The truncation reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like list-outlook-contacts or update-outlook-contact. The description does not specify context or alternatives, failing to help the agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds no behavioral context. It does not describe side effects, error conditions, or what happens on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly minimal. It could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, 4 parameters, no output schema), the description is severely incomplete. It fails to explain the return value, error scenarios, or the role of the bucket in Planner.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, but the description adds no parameter information. It does not explain the purpose of the required 'body' parameter or fields like 'name' and 'planId', leaving the agent to rely solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new plannerBucket object.' clearly specifies the verb 'Create' and the resource 'plannerBucket', which is distinct from siblings like update or delete. However, it does not elaborate on what a planner bucket is or its role in the planner hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create-planner-task or list-plan-buckets. There is no mention of prerequisites like requiring an existing plan ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations (readOnlyHint, destructiveHint) already provide. There is no mention of pagination, payload sizes, or that fetchAllPages can return enormous payloads (though that is in the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but too minimal. It fails to provide key information such as the nature of the HTML content or behavioral notes. Front-loaded but insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and the tool capable of returning large payloads (via fetchAllPages), the description omits critical context about what the HTML content represents, how to handle pagination, or the structure of the response. The description is incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have descriptions in the input schema (100% coverage), so the description does not need to add parameter semantics. It adds no new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'The page's HTML content' vaguely states the output but does not explicitly state the tool's action (getting/retrieving). It relies on the tool name to convey purpose. It distinguishes from siblings like list-onenote-pages but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as list-onenote-pages or other page operations. Does not mention prerequisites, context, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description adds minimal value. It mentions folder location but lacks details on side effects, required fields, or what happens on duplication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and to the point. No wasted words, though it could be slightly expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not explain return values (e.g., created contact ID). For a creation tool, this is a significant omission. Also, the mention of 'another contact folder' is not reflected in parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already explains most parameters. The description adds no extra parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it adds a contact to the root folder or another folder, but the input schema lacks a folder parameter, causing ambiguity. It does not distinguish from the sibling tool 'create-contact-in-folder' which likely handles folder targeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'create-contact-in-folder' or 'list-outlook-contacts'. The description does not specify context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true and destructiveHint=false. The description reiterates 'read-only', which adds no new behavioral insight beyond the annotations. No additional traits disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (6 words), but overly brief for a tool with 6 parameters. Lacks front-loaded actionable guidance; underspecified for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, but the description does not explain what is returned or how to use parameters like expand or select. Incomplete for a tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema itself documents all parameters. The description adds no parameter information, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (the root folder of the drive) and notes it's read-only, but lacks an action verb like 'get' or 'retrieve'. It does not distinguish from similar tools like 'get-drive-item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get-drive-item' or 'list-folder-files'. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds no new behavioral info beyond the fact that it creates a chart.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks substantive information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief for a tool with 7 parameters and no output schema. It fails to convey important context about the chart creation process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the schema already documents most parameters. The description adds no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Creates a new chart.' clearly states the action and resource, but does not differentiate from sibling tools like create-excel-table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, but description adds no behavioral context (e.g., authorization requirements, side effects, or what gets created). The description fails to disclose beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified for a complex tool with many parameters. It lacks front-loading of key information and wastes the opportunity to guide usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested objects, no output schema), the description is critically incomplete. No mention of required fields, return values, or typical usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (many parameters have descriptions in schema). The description adds no extra meaning; it simply reiterates the tool's action. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new plannerTask', specifying the verb 'Create' and the resource 'plannerTask'. This distinguishes it from sibling tools like list-planner-tasks, update-planner-task, and delete-planner-task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No prerequisites mentioned (e.g., needing a planId or bucketId). The description lacks context on required inputs or setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the destructive nature already declared by annotations (destructiveHint=true). It adds no additional context such as whether deletion is permanent, moves to recycle bin, requires specific permissions, or has side effects. No new behavioral traits are disclosed beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified for a destructive tool with 6 parameters. While there is no fluff, it does not earn its place by adding enough value; it is more like a label than a full description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema, the description should explain return values, error behavior, or the scope of deletion. It provides none of that. The schema covers parameters, but the description lacks necessary contextual completeness for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description itself adds no parameter-level meaning beyond what the schema already provides, such as clarifying that driveItemId refers to a file or explaining the confirm gate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a OneDrive file' clearly states the action (delete) and resource (OneDrive file), making the tool's purpose unambiguous. It distinguishes from sibling tools like copy-drive-item or move-rename-onedrive-item, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites, exclusions, or scenarios where this tool is not appropriate. It offers no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds the max size constraint and required body format, which are useful. However, it does not disclose other behaviors like error conditions, return values, or side effects. Adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains a confusing and incomplete sentence about attachment types. The tip is useful but could be better integrated. It is not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested objects, no output schema), the description lacks completeness. It does not explain the response format, prerequisites (e.g., message must be draft), or error cases. The absence of output schema information is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 80%, providing a baseline of 3. The description adds significant value by specifying the exact body format required (including @odata.type, name, contentBytes) which is not in the schema. The messageId parameter is already well-documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates attachments, but it is vague about attachment types and does not distinguish this tool from sibling tools like create-mail-attachment-upload-session. The purpose is moderately clear but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only gives a tip about size and body format but no exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's main behavioral contribution is noting the ability to retrieve calendars from the default or a specific group. This adds some context but does not disclose additional traits like pagination behavior or auth scope beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence but somewhat repetitive ('Get all the user's calendars..., get the calendars...'). It is not overly long, but could be more concise by avoiding the repeated structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief and lacks details about the return format, typical usage patterns, or how to handle pagination. Despite the schema covering parameters, a user would benefit from knowing what information is returned per calendar (e.g., id, name, color). The tool has 11 parameters and no output schema, so more context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no information about parameters. All parameter documentation is in the schema, so the description provides no additional value for understanding parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves calendars, specifying both from the default group and specific groups. It uses a specific verb ('Get') and resource ('user's calendars'), but does not explicitly differentiate from related tools like 'get-calendar' or 'list-specific-calendar-events', though the resource type is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when to choose this over other calendar listing tools (e.g., for specific groups vs. default), nor does it provide context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that it is 'Read-only. Nullable' and details each version's fields (id, lastModifiedDateTime, etc.), which is beyond the annotations (readOnlyHint true). However, it does not disclose other behavioral traits like empty responses or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but contains some redundancy (e.g., 'Read-only. Nullable.' from original API). The structure is acceptable but could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters and no output schema, the description falls short. It lacks information about response format (beyond fields), pagination, common use cases, and error conditions. Incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter meaning beyond the schema. The tip about version fields pertains to output, not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists previous versions of an item. Verb 'list' and resource 'versions of the item' are unambiguous. However, it does not explicitly distinguish from sibling tools, but the uniqueness of version listing versus other drive operations is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The tip only suggests a follow-up action (downloading a version) but does not explain prerequisites or context for invoking the tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats 'Read-only', which is already indicated by readOnlyHint=true. It adds no new behavioral context such as error handling, authentication, or response structure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise. However, it could include more useful information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no output schema), the description is too minimal. It does not explain what worksheets are included, how results are structured, or any pagination or error handling. More detail is needed for an AI agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter meaning beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it represents a collection of worksheets, which implies listing. The name 'list-excel-worksheets' makes the purpose clear, and it is distinguishable from sibling tools like 'list-excel-tables'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list-excel-tables' or other Excel tools. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Create a new calendar' which implies a constructive, non-destructive operation, but the annotation declares destructiveHint=true. This is a direct contradiction. No additional behavioral traits (permissions, reversibility) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a tip. The first sentence immediately states the purpose, and the tip provides a practical example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the complexity of the input schema (nested object, 4 parameters), the description is minimal. It omits any mention of return values (no output schema), user context (which user's calendar?), or important behaviors like confirm parameter. Leaves the agent with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (75%), so baseline is 3. The description adds an example body ({ name: 'My Calendar', color: 'auto' }) and lists available colors, but does not cover other schema-less parameters like confirm, includeHeaders, or excludeResponse. It adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and resource 'calendar', and specifies 'for a user' and 'personal calendar'. It distinguishes from sibling tools like update-calendar or delete-calendar by focusing solely on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as create-calendar-event or update-calendar. The description lacks any when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read behavior. The description adds no additional behavioral context (e.g., pagination handling, result size limits) beyond what the annotations and schema provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but given 11 parameters and a complex API, it is overly minimal. It lacks structure or front-loading of key information, though it has no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage, the description fails to provide complete context for usage. It does not mention output format, typical use cases, or how to effectively combine parameters, leaving the agent to infer from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter thoroughly described in the schema. The tool description does not add any parameter-level details beyond the schema, so it meets the baseline but does not excel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and the resource ('list of notebook objects'), making the purpose unambiguous. It distinguishes from sibling tools by specifying notebooks, which is a specific OneNote resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., list-onenote-sections, list-onenote-pages). No exclusions or context for usage are mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a destructive operation (destructiveHint=true, readOnlyHint=false). The description says 'renew,' which is consistent, but it adds little behavioral detail beyond the annotations. It does not mention potential side effects or what happens if renewal fails, relying on the annotations to convey non-read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, with a clear purpose statement followed by a tip. It front-loads the main action but includes somewhat verbose caveats about resource types and documentation. Could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, nested body, destructive hint, no output schema), the description does not fully cover expected outcomes or error scenarios. It lacks details on what the response looks like or common failure modes. More completeness is needed for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so baseline 3. The description adds value by focusing on the body's expirationDateTime and subscriptionId, including a tip on usage. However, many nested body properties are not explained in the description, leaving some parameter semantics to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renews a subscription by extending its expiry, using a specific verb ('renew') and resource ('subscription'). It distinguishes from siblings like create-subscription or delete-subscription, though it does not explicitly compare. The tip reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises renewing well in advance of expiry and mentions checking resource-type-specific maximum extensions. It provides context for when to use the tool but does not explicitly state when not to use it or mention alternatives. The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as destructive (destructiveHint=true). Description adds the uniqueness constraint on displayName, which is useful but not comprehensive—does not mention error behavior on duplicate names or side effects like sharing or default notebook creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short (two sentences plus tip), but the tip is partially redundant. Front-loads the core purpose. No unnecessary detail, though it could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description does not explain return value. Does not mention the confirm gate parameter, which is important for a destructive operation. Lacks details on user or scope (e.g., current user's notebooks). Missing information about prerequisites or post-conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and describes body extensively. Description adds an example body format and the uniqueness rule for displayName, providing modest value beyond the schema. The confirm and other headers are not mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Create a new OneNote notebook' with a tip clarifying the body format and uniqueness constraint. Clearly identifies the resource and action, though it does not differentiate from siblings like list-onenote-notebooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., create-onenote-section, create-onenote-page). Does not specify context such as user authentication or typical workflow order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations already indicate destructiveHint=true and readOnlyHint=false. The description does not disclose permanence, consequences, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three words), but it omits useful information that could be included without significant verbosity. It is not overly long, but it could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with annotations covering destruction, the description is minimally complete. However, it lacks details on return behavior or error handling, which could be beneficial given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description does not add any additional meaning or usage tips beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a contact'), making the tool's purpose unambiguous. It effectively distinguishes from sibling tools like 'update-outlook-contact' and 'create-outlook-contact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., other delete tools). There is no mention of prerequisites or conditions for safe use, which is critical for a destructive action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds no additional behavioral context such as pagination behavior or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the purpose. It is front-loaded but could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and many sibling tools, the description is too sparse. It does not explain how to specify the target (User, Group, Site) or what the response contains, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds no further meaning beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'retrieve' and resource 'list of Drive resources', and mentions target scope (User, Group, Site). However, it does not differentiate from sibling tools like 'get-drive-root-item' or 'list-folder-files' which also list items within drives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list-folder-files' or 'search-onedrive-files'. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint, destructiveHint=false). However, it adds no behavioral details beyond what annotations provide. It does not mention pagination behavior, response size implications, or any side effects. The parameter descriptions on the schema handle some details, but the description itself is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is appropriately concise. It front-loads the core purpose. It could be slightly more informative without becoming verbose, but it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema, the description is too brief. It does not explain the structure of the returned list, how to handle pagination, or the relationship to plannerPlan. The parameter descriptions in the schema compensate partially, but the tool's purpose and usage context are insufficiently covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description itself does not describe any parameters; all parameter meaning is derived from the schema. This is acceptable given high coverage, but the description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of plannerBucket objects for a plannerPlan. It uses a specific verb ('Retrieve') and resource, and the name reinforces the purpose. While it doesn't explicitly contrast with sibling planner tools, the resource 'buckets' vs 'tasks' or 'plans' provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., list-plan-tasks, get-planner-plan). There is no mention of prerequisites (e.g., having the plannerPlanId) or constraints like the need for specific permissions. The description offers no when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. However, the description adds minimal behavioral context beyond the annotations; it only adds a tip about priority values, which is data semantics rather than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and includes an optional tip. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no output schema), the description is adequate but minimal. The schema descriptions handle parameter details, but the main description lacks high-level context such as authentication requirements, response structure, or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The main description does not add parameter information beyond the schema, but the tip about priority values provides extra context for interpreting task data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve a list') and the resource ('plannerTask objects associated with a plannerPlan object'). It distinguishes from sibling 'list-planner-tasks' by specifying association with a plan, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without any context about prerequisites, limitations, or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, signaling a mutation tool. The description adds minimal behavioral context beyond stating the calendar scope (user or group). It does not disclose side effects, permission requirements, or rate limits, providing limited extra value over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a tip, totaling about 60 words. It front-loads the core purpose and includes a helpful callout. However, it could be slightly more structured by explicitly separating the event creation scope from the tip.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the body parameter with many nested fields, the description is minimal. The schema compensates with detailed descriptions for many properties. However, there is no output schema, and the description does not explain return values or typical usage patterns, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 80%, the baseline is 3. The description does not add meaning beyond what the schema already provides for parameters like body, calendarId, confirm, includeHeaders, excludeResponse. The tip about attendees relates to usage guidance rather than parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new event in a calendar, specifying the verb 'create' and resource 'event'. It mentions calendars for users or Microsoft 365 groups. However, it does not explicitly differentiate from the sibling 'create-calendar-event' tool, which might create an event in a default calendar without requiring a calendarId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a critical tip about not guessing email addresses and using list-users, which provides guidance for a common use case (adding attendees). However, it lacks explicit instructions on when to use this tool versus other calendar event creation tools, and does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description confirms 'Read-only' but adds no further behavioral context (e.g., authentication needs, rate limits, side effects). It adds limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with two sentences and a tip. The first sentence is redundant with annotations. The tip adds useful context. Could remove the first sentence for better conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists some returned properties (columns, showHeaders, showTotals, style), which helps. However, it does not mention pagination or usage of expand/select parameters, which are important for a get operation. Lacks some completeness for a tool with 8 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are fully described in the schema. The description mentions fetching by 'name or ID' but does not clarify which parameter corresponds to name vs ID; the schema has workbookTableId, which is an ID. No additional semantic meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Gets a specific table by name or ID' and lists returned properties, which clearly identifies the tool's function. However, the first sentence 'Represents a collection of tables' is slightly misleading as it implies a list rather than a single table. It distinguishes from siblings like list-excel-tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., list-excel-tables). The description implies using it for a specific table but does not exclude other use cases or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false. The description adds the condition about folder/package facet, which is useful context. However, it does not disclose pagination behavior or response size limits, though the schema detail covers pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and paging complexity, the description is too minimal. It doesn't explain the response structure, error handling, or that it returns an OData collection. Open world hint implies variability, but more context on usage patterns would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description does not add parameter-level meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns child DriveItems from a folder/package. It specifies the resource (DriveItem children) and the condition (non-null folder or package facet). It distinguishes from similar siblings like get-drive-item (single item) and list-drive-item-versions, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like search-onedrive-files or get-drive-delta. The description doesn't mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only says 'Authenticate with Microsoft account' without explaining side effects like token storage, UI prompts, or what happens when already logged in. The 'force' parameter hint is in schema but not integrated into description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the essential purpose. Every word contributes value; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves authentication, which typically has side effects and requires context (e.g., returns a token, affects session). The description omits these details, and with no output schema, the agent lacks information on what to expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter with a description 'Force a new login even if already logged in' (100% coverage). The tool description adds no additional meaning beyond the schema, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'authenticate' and the resource 'Microsoft account', making the tool's purpose unambiguous. It is distinct from sibling tools like 'verify-login' and 'select-account'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'verify-login' to check status or 'remove-account' to log out. No prerequisites or context for usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats the destructive nature already captured by the destructiveHint annotation. It adds no extra context such as confirmation requirements, permanence, or potential side effects. With annotations already disclosing destructiveness, the description contributes no additional behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is direct and free of unnecessary words. It front-loads the core purpose without fluff, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations (destructiveHint) and full schema coverage, the description is minimally sufficient. However, it lacks context about the confirmation gate (confirm parameter), return behavior, or prerequisites. This leaves some gaps for an agent, but the tool is simple enough that the description is just adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already well-described. The description adds no parameter-level meaning. Baseline of 3 is appropriate since the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a mail attachment' clearly states the action (delete) and the specific resource (mail attachment), which distinguishes it from sibling tools like delete-mail-message or add-mail-attachment. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of when not to use it or references to sibling tools like list-mail-attachments or delete-mail-message. Usage is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, but the description provides no additional behavioral context such as whether existing formatting is overwritten, permission requirements, or the meaning of the confirm parameter. The schema's confirm flag is not mentioned in the description, leaving the agent to infer important safety and mutation semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a direct statement followed by a useful tip listing the key adjustable fields. There is no fluff or redundant information; every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward formatting action, given the high schema coverage and existing annotations. However, it lacks information about return values, side effects (e.g., overwriting existing font settings), and any usage prerequisites. For a mutation tool with no output schema, additional behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (88%), with individual descriptions for name, size, and color. The description simply lists the same properties without adding new semantics or clarifying usage patterns. Baseline 3 is appropriate as the schema carries the explanatory burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "Format an Excel range font" and explicitly lists the adjustable attributes (bold, italic, underline, size, color, font name). This distinguishes it from sibling tools like format-excel-range-fill or format-excel-range-border, which target different formatting aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as format-excel-range-fill or format-excel-range-border. It does not specify exclusions, prerequisites, or context for optimal use, relying solely on the tool name and basic tip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses that event bodies are returned only in HTML format and that extensions are supported for custom properties. This adds valuable behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs with some redundant phrasing (e.g., 'Since the event resource supports extensions...'). It could be more concise by trimming unnecessary elaboration, but it is not overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and moderate complexity, the description covers basic purpose and a few behavioral traits but lacks information on pagination, error handling, or response structure. It is adequate but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so baseline is 3. The description adds little beyond what the schema provides—it mentions the HTML format but no parameter-specific details. Baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('properties and relationships of the specified event object'). It also mentions that it returns HTML body and can access other users' calendars, but does not explicitly differentiate from sibling tools like get-calendar-view or get-specific-calendar-event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions two scenarios for getting events in another user's calendar, but provides no explicit guidance on when to use this tool versus list-calendar-events or other get tools. No prerequisites or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description is less burdened. It adds formatting details for date/time/timezone and provides an example, but does not disclose what settings are overwritten or other behavioral traits like server-side impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but somewhat lengthy due to the tip and example. It is front-loaded with a general statement but includes unnecessary details like '💡 TIP' and example, which could be shortened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description focuses solely on the 'body' parameter content and ignores other parameters (confirm, includeHeaders, excludeResponse). With no output schema and 4 parameters, it fails to explain how to use the confirm gate or get response headers, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema coverage, the description adds value beyond the schema by explaining formatting constraints for date/time/timezone and giving a complete example for automatic replies, which clarifies the structure of nested objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'enables, configures, or disables mailbox settings' and lists specific settings (date format, time zone, automatic replies). It provides a concrete example and formatting tips, distinguishing it from the read-only sibling get-mailbox-settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a context tip and example for common use (Out-of-Office), but does not explicitly state when to use this tool versus alternatives (e.g., get-mailbox-settings for reading, or other update tools). It implies usage for changing mailbox settings but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tip about emailAddresses being replaced entirely reveals a key behavior not covered by annotations (destructiveHint=true, readOnlyHint=false). However, the description omits other important behaviors: it does not mention the confirm parameter for destructive operations, the overwrite behavior of displayName, or that the tool returns the updated contact object. Annotations already indicate destructiveness, so the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: one clear sentence plus a tip. Every word serves a purpose, and the critical information (replacement behavior) is front-loaded in the tip. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many properties, nested objects, no output schema), the description is incomplete. It does not explain return values, required fields (contactId), or the overall update behavior (e.g., which fields are updatable, handling of null). The tip is helpful but insufficient for comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 80%, the baseline is 3. The description adds meaningful context for the emailAddresses parameter (replace behavior) beyond the schema's simple description. For other parameters, the description provides no additional semantics, but the tip alone elevates the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update the properties of a contact object,' clearly indicating a verb and resource. The title 'update-outlook-contact' further reinforces this, distinguishing it from create, get, delete, and list operations among siblings. However, the description does not explicitly differentiate from other contact tools, limiting clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a behavioral tip but offers no explicit guidance on when to use this tool versus alternatives like 'create-outlook-contact' or 'get-outlook-contact.' There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage solely 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description adds 'permanently' which confirms destruction but does not add other behavioral details like authentication needs, rate limits, or what else might be affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a tip. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with good annotations and full schema coverage, the description adequately covers the core action. The tip adds useful context. Could mention return value expectations, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'messageRule object'. It is specific and distinguishes from sibling tools like create-mail-rule and update-mail-rule, though it does not explicitly differentiate from other delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a tip about using the Inbox folder ID for inbox rules, but it does not provide explicit when-to-use vs alternatives or when not to use. No guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the read-only nature (already indicated by annotations) without adding behavioral insights like pagination behavior, potential data volume, or any side effects. The parameter schema covers pagination details, but the description itself adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently captures the tool's purpose with no unnecessary words or fluff. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of the tool (list operation with many optional parameters) and the absence of an output schema, the combination of a concise description and thorough parameter schema provides adequate context. However, a note about typical return structure or nextLink handling would increase completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 12 parameters, so the schema already provides full meaning for each parameter. The description does not add further semantics; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve a list'), the resource ('onenoteSection objects'), and the scope ('from the specified notebook'). This distinguishes it from sibling tools like 'list-all-onenote-sections' (all sections across notebooks) and 'list-onenote-section-pages' (pages within a section).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list-all-onenote-sections' or 'list-onenote-section-pages'. The description does not mention prerequisites, common use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds value by explaining the category structure (displayName, color range), but does not disclose additional behavioral traits like auth needs or rate limits. This is adequate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a tip. It is front-loaded with the main purpose. The tip is useful but slightly verbose; still, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 11 parameters and no output schema, the description is minimal. It explains category structure but does not discuss pagination, filtering, or response handling. Schema descriptions are rich, so completeness is adequate but not outstanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only mentions category fields but does not relate them to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all the categories...' and explains what categories are (colored labels). The tip mentions use with update tools, but does not explicitly distinguish from the sibling 'create-outlook-category', so it's clear but not differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip provides a clear use case ('show available tags before applying'), but no guidance on when not to use this tool or when to use alternatives like 'create-outlook-category'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds a useful tip about priority value mappings but does not disclose other behaviors such as pagination, filtering support, or rate limits. With annotations covering safety, the description provides adequate but not exceptional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and a useful tip. No wasted words, and the information is front-loaded. The structure is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 11 parameters and no output schema, the description is minimal but the schema descriptions fill the gaps. The description provides the core purpose and a helpful tip. It is complete enough for an agent that can read the schema, but could benefit from a brief note on typical usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds a tip about priority values, which is contextually useful but not directly about parameters. It does not significantly enhance understanding beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (retrieve) and resource (plannertask objects) and specifies the scope (assigned to a User). However, it does not explicitly state which user (likely the current authenticated user), leaving some ambiguity. The sibling 'list-plan-tasks' is distinct but no differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives like 'list-plan-tasks' or other planner tools. It lacks explicit when/when-not criteria or mentions of prerequisites. The tip about priority values is unrelated to usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a tip about silently accepting by setting sendResponse to false, but does not disclose other behavioral aspects such as modification of event status, requirement for organizer notification, or irrereversibility. Annotations already indicate destructiveHint: true, so the description adds marginal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence plus a tip. It includes a visual cue (💡 TIP) and uses front-loaded key information. No superfluous content. Could be slightly more structured with a clear 'When to use' section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information on prerequisites (e.g., authentication, calendar permissions), what happens on success (no output schema), and potential side effects beyond the tip. Given the complexity (5 parameters, nested objects), the description feels incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a tip that adds meaning to the body parameter (e.g., comment and sendResponse usage) beyond the schema's property definitions. However, schema coverage is 80%, so the description does not need to compensate much; it adds useful context for the body parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Accept the specified event in a user calendar' with a specific verb and resource, and the tip clarifies it's for meeting invitations, distinguishing it from sibling tools like decline-calendar-event or tentatively-accept-calendar-event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus other calendar event actions (e.g., tentatively-accept, decline). The tip is about how to use the optional body, not about selecting between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true, but the description does not explain destructive implications (e.g., confirmation requirements). It adds context about the resource association but omits behavioral details like the need for user approval when the confirm gate is enabled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, front-loads the purpose, and includes a helpful tip. It could be trimmed slightly, but overall it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and gives an example, but it does not mention return values (no output schema exists) or clarify parameters like confirm, includeHeaders, or excludeResponse. With 6 parameters and no output schema, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), so baseline is 3. The description adds value with an example body structure ('{ webUrl: 'https://...', applicationName: 'Mail', ...}'), clarifying parameter usage beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a linkedResource to associate a task with an item in a partner application, with a concrete example. It does not explicitly distinguish from sibling tools like create-todo-task or list-todo-linked-resources, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example use cases (email association, during task creation) but lacks explicit guidance on when not to use this tool or alternatives. The usage context is implied but not systematically covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, so the description's 'Delete' is consistent. It adds the tip about removing from a To Do task, but does not disclose further behavioral details like cascading effects, permissions, or reversibility. The description adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence plus a tip emoji line. Every word earns its place, and there is no unnecessary fluff. It is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 7 parameters and no output schema, the description offers minimal context. It states the action and resource but does not explain return values, prerequisites, or consequences. While schema descriptions cover parameters, the tool description itself lacks completeness for an agent to fully understand usage without additional lookups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description does not add any additional meaning or context for parameters (e.g., source of IDs). Baseline 3 is appropriate as description provides no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('linkedResource object'), with a tip specifying it removes a linked resource from a To Do task. It distinctly differentiates from sibling delete tools (e.g., delete-todo-task) by focusing on linked resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives or when not to use it. While the tip adds context (from a To Do task), it does not help differentiate usage from other delete operations among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's statement that it dismisses a reminder is consistent. It adds the detail that no request body is required, but does not disclose other behavioral traits like idempotency or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences and a tip. Every sentence adds value, and the key information is front-loaded. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and lacks an output schema. The description does not explain return values or response structure, which may leave agents uncertain about success/failure indications. Given the low complexity, the gap is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described in the schema. The description adds minimal value beyond stating that no request body is required, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Dismiss') and resource ('a reminder that has been triggered for an event in a user calendar'). It is specific and avoids tautology, though it does not explicitly distinguish from the sibling tool 'snooze-calendar-event-reminder'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip provides guidance on when to use this tool with associated listing tools, but it lacks explicit exclusions or mention of alternatives like snooze. The context of pairing with list-calendar-events is helpful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only says 'Log out'. It does not disclose token invalidation, session effects, or whether authentication 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and efficient, containing no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameters, the description is adequate but could mention the expected outcome (e.g., success indication) for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%. The description correctly confirms no parameters are needed, meeting the baseline for 0-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Log out') and the target resource ('Microsoft account'), distinguishing it from sibling tools like 'login' and 'verify-login'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'remove-account'), nor does it mention any prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It indicates a state-changing mutation ('Select as default') but does not disclose side effects, persistence, or authentication requirements. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with zero wasted words. Every sentence serves a purpose: main action, accepted input format, and reference to sibling tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple selection tool, the description adequately covers the basic purpose and input. However, it lacks information about return values, how to verify the current default, or whether selection persists across sessions. Moderate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description already fully covers the parameter (100% coverage). The description adds an example (e.g., user@outlook.com), which is helpful but not essential. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Select a Microsoft account as the default' with a specific verb and resource. It distinguishes from 'list-accounts' by mentioning discovery, but does not differentiate from other account-related tools like login, logout, or remove-account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly advises using 'list-accounts' first to discover available accounts, providing clear context for when to use this tool. It does not include exclusion criteria or alternatives beyond list-accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a valuable behavioral warning: 'Setting attendees replaces the entire attendee list — include all attendees, not just new ones.' The annotations already mark the tool as destructive (destructiveHint: true) and the description's 'Update' aligns with that. No contradiction exists. This warning provides context beyond annotations, though other side effects (e.g., what happens to omitted fields) are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose ('Update a specific calendar event') and includes only two additional sentences. Both the tip about list-users and the warning about attendees are critical and earn their place. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal, but the schema and annotations provide substantial context (e.g., required parameters, destructiveHint). However, it does not clarify the difference from 'update-calendar-event' or the confirmation behavior (the confirm parameter is described in the schema but not the description). Given the tool's complexity and the absence of an output schema, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 83% description coverage, so the baseline is 3. The description adds a tip about using list-users to find email addresses (relevant to the attendees parameter) and warns about attendee replacement, but it does not explain the body structure, confirm parameter, or other semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update a specific calendar event') with a specific verb and resource. However, it doesn't explicitly differentiate from the sibling tool 'update-calendar-event', relying on the name 'specific' and the presence of calendarId/eventId parameters to imply that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the similarly named 'update-calendar-event' or other calendar update tools. The only cross-tool reference is 'Use the list-users tool to find the email address', which is an operational tip for a sub-task, not a usage guideline for the tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's mention of 'create' is consistent and adds little beyond the listed features (online meetings, recurrence). No contradictory information is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a tip, no wasted words. The most important information (what the tool does) is front-loaded. The tip is emphasized but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex input schema with many optional fields and no output schema. The description covers core features and a critical tip, but does not mention what the tool returns (presumably the created event) or any other contextual notes like behavior with online meetings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has high (75%) description coverage, so the description does not need to detail each parameter. It summarizes the key adjustable fields (subject, times, etc.) and adds the email tip, which is more of a usage guideline. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new calendar event on the user's default calendar, listing the main settable attributes (subject, times, location, attendees, etc.). This distinguishes it from sibling tools like create-specific-calendar-event (which targets a specific calendar) and update-calendar-event (which modifies existing events).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a critical tip to use list-users to find recipient email addresses, but does not explain when to use this tool versus create-specific-calendar-event or other alternatives. There is no guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, so the description's 'Delete' is consistent but adds no extra behavioral context beyond what annotations provide. The description does not mention idempotency, irreversibility, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the action and target. It is highly concise and front-loaded with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with no output schema and annotations already signaling destructiveHint, the description is sufficiently complete. However, it could mention irreversibility or the confirm gate, though those are covered by annotations and parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 6 parameters with descriptions, achieving 100% coverage. The tool description does not add any additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('delete') and the resource ('a todoTask object'). It distinguishes this tool from siblings like create-todo-task, update-todo-task, and get-todo-task by specifying the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no usage guidance. It does not indicate when to use this tool, prerequisites (e.g., need task ID), or when not to use it (e.g., alternatives for soft-delete or undo). The sibling tools include related operations, but no explicit comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds only that it sets the background color, implying an overwrite. It does not disclose details such as whether existing fill formatting is completely replaced or what confirmation behavior may apply, but there is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, but the first sentence ('Format an Excel range fill.') largely restates the tool name. The tip provides the substantive clarification, so while the description is not padded, one of its two sentences is mostly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain return values, failure modes, or the precise effect on existing fill formatting. However, the schema covers parameters and annotations provide destructiveness awareness, making this barely adequate for a simple fill-setting operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (88%), with clear descriptions for body.color, address, and path segment parameters. The description does not add parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Format'/'Set') and resource ('Excel range fill'/'background fill color'), and the tip clarifies this tool is specifically for background fill. This distinguishes it from sibling formatting tools like format-excel-range-border and format-excel-range-font.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for setting background fill colors, but it gives no explicit guidance on when to use it versus the more generic format-excel-range or other formatting siblings. No exclusions, prerequisites, or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. However, the description adds no extra behavioral context beyond stating it retrieves properties and relationships, which is minimal. The agent gains no insight into side effects, auth needs, or data scope 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It efficiently conveys the tool's core action without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple retrieval operation with a well-documented schema and no output schema, the description is mostly adequate. However, it could benefit from a note about what 'properties and relationships' typically include, especially since there is no output schema to clarify the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 6 parameters, so the descriptive burden on the main description is low. The main description does not add any parameter-specific context, which is acceptable since the schema already does a thorough job.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a planner plan object. The purpose is specific, but it does not explicitly differentiate from sibling tools like list-planner-tasks, which could be confusing for an AI agent determining which tool to use for a specific plan retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing properties of a specific plan, but it offers no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or context for invoking it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining that the property includes occurrences that are part of the recurrence pattern and exceptions, but excludes canceled occurrences. It also confirms read-only behavior, aligning with annotations. This helps the agent understand the data scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with a clear tip at the start using a symbol. The first sentence is somewhat technical but informative. Overall, it is well-structured and front-loaded, with no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters, no output schema), the description is adequate but incomplete. It explains the input requirements but does not describe the response format (e.g., list of event instances). An agent might need to infer the output from the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% parameter schema coverage, the baseline is 3. The description does not add significant new meaning beyond the schema; the tip mentions start and end date format, which is already covered in the schema descriptions. Thus, no extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists occurrences of a recurring calendar event within a date range. It specifies that it is a navigation property and read-only. However, it does not explicitly differentiate this tool from similar calendar tools like list-calendar-events or get-calendar-event, which could confuse selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a tip that requires startDateTime and endDateTime in ISO 8601 format, providing essential usage guidance. However, it does not specify when to prefer this tool over alternatives (e.g., for non-recurring events), nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by warning about attendee list replacement. However, it does not disclose other behavioral traits such as permission requirements, rate limits, or whether the update is partial or full replacement. Annotations already mark destructiveHint=true, so the description adds moderate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences plus tip/warning) and front-loaded with the main purpose. It is efficient with no fluff, though the structure could be improved with a more formal layout.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, nested objects, destructive nature) and no output schema, the description covers some behavioral aspects (attendees replacement) but lacks information on return values, error handling, or confirmation gate behavior. It is reasonable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 80%, the schema already documents most parameters in detail. The description does not add any new information about parameters beyond what the schema provides, hence baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update the properties of the event object', which is a specific verb ('Update') and resource ('event object'). However, it does not differentiate this tool from its sibling 'update-specific-calendar-event', which updates events in a specific calendar rather than the default calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: do not guess email addresses (use list-users tool) and warns that setting attendees replaces the entire list. It lacks explicit when-to-use vs. alternatives, but the tip and warning are helpful for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'check current status' without detailing behavior (e.g., network request, what status means, return type). Misses opportunity to disclose side effects or lack thereof.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Purpose is front-loaded and immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description sufficiently conveys the tool's purpose for a simple status check. Could specify return value format (e.g., boolean) but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline 4 applies; description adds no parameter info but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks Microsoft authentication status, distinguishing it from sibling tools like login or logout. Verb 'check' and resource 'authentication status' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., before operations that require authentication). The description does not state context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims creation of a draft (non-destructive), but annotations declare destructiveHint=true, creating a direct contradiction. Per guidelines, a contradictory description scores 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and location, followed by a clarifying remark about saving vs sending. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides a decent overview but lacks information about the return value (no output schema) and does not mention all possible input fields like attachments or BCC. Adequate for a straightforward tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema description coverage, the description adds value by summarizing the key settable fields (subject, body, toRecipients, ccRecipients, importance), helping the agent focus on important parameters, though it omits others like attachments and flags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (create), resource (draft Outlook email message), and location (Drafts folder). Lists key fields that can be set and distinguishes from send-mail by clarifying that the draft is saved, not sent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: use to create a draft for later sending. Names an alternative tool (send-mail) for direct sending. Does not mention other draft creation tools like create-reply-draft or create-forward-draft, which are siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description presents the operation as a benign 'create' action that returns a short-lived URL, yet the annotations set destructiveHint=true. This is a direct contradiction: no mention of destructive effects or reasons for the destructive flag. The description also fails to explain why a preview creation would be considered destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main action. The emoji and tip format are slightly informal but every sentence adds useful information, including body structure, return values, and a practical use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description still explains return values, body options, and short-lived nature, which is good. It omits discussion of the destructive hint and confirm gate, but those are already exposed via annotations and parameter descriptions, so the overall picture is adequate for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, and the description adds the 'viewer' option not present in the schema, and clarifies that return values are getUrl and postUrl. These additions meaningfully supplement the schema descriptions, which already cover driveId and driveItemId well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a drive item preview and explains that it generates a short-lived embeddable preview URL for files. It distinguishes itself from sibling tools like share-link or download-url by focusing on inline previews for summary emails or chat messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a concrete use case: 'surfacing inline previews in summary emails or chat messages without needing the recipient to open the file.' It does not explicitly exclude alternate tools, but the context is clear enough for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds behavior details like date/time format handling and time zone format support (Windows vs IANA), which goes beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat verbose, especially the paragraph about date/time and time zone behavior. The TIP adds value but the structure could be leaner. Not overly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists some return settings but lacks details on response structure (e.g., JSON object shape). It adequately explains behavior but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description does not add parameter-specific info beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets user mailbox settings and lists specific settings (automaticRepliesSetting, language, timeZone, etc.), distinguishing it from sibling tools like update-mailbox-settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is for reading settings, but no explicit guidance on when to use vs. update-mailbox-settings or other sibling tools. The 'TIP' indicates it gets current user settings, but lacks direct when-to-use/when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no behavioral details beyond 'retrieve', which is consistent with annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 12 words with no wasted words. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, 1 required, no output schema), the description is minimal. While the schema descriptions are comprehensive, the overall description does not summarize key capabilities like pagination, filtering, or response format, which could help the agent quickly grasp the tool's full capability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed parameter descriptions. The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve'), the resource ('a list of page objects'), and the scope ('from the specified section'). It distinguishes itself from sibling tools like 'create-onenote-section-page' (creation) and 'list-onenote-pages' (potentially all pages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives (e.g., list-onenote-pages). The tool name and context imply it is for pages within a specific section, but no when-not or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat that. The description adds that the tool searches by name/content and returns specific fields, but does not disclose pagination behavior, rate limits, or other traits beyond what parameter descriptions cover. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences plus a tip, all front-loaded. Every sentence provides essential information without redundancy. The tip is practical and well-placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, OData features), the description adequately covers the purpose and prerequisite. The parameter descriptions handle the rest. The description could mention pagination or compare to list-folder-files, but it's fairly complete for the annotations and schema provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds value by explaining the search scope (folder hierarchy, whole drive, shared files) and the nature of the q parameter (searches names, metadata, content), which goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for items matching a query within OneDrive, specifying search scope (folder hierarchy, whole drive, shared files). It mentions search by name/content and lists return fields. However, it does not explicitly distinguish from sibling tools like list-folder-files, though the distinction is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using list-drives first to get the drive-id, which is a helpful prerequisite. It also clarifies the q parameter. However, it does not provide explicit when-to-use vs alternatives (e.g., when to use search vs list-folder-files) or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description adds that it saves in Sent Items and requires an existing draft. However, it does not elaborate on other behavioral aspects such as permissions or side effects beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—two sentences plus a tip—with no unnecessary words. It front-loads the purpose and provides a clear tip about usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not clarify return values or error handling. However, for a simple send action, the essential information is present, and the tip covers the key requirement. It could be more complete but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond what the schema provides for parameters; it only repeats that no request body is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sends an existing draft message, listing types (new, reply, reply-all, forward) and mentions saving to Sent Items. It also distinguishes from sending a new message in one operation, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a tip that no request body is needed and draft must exist in Drafts folder, but it does not explicitly compare with sibling tools like send-mail or create-draft-email, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and description mentions MIME saves to Sent Items. No annotation contradiction. However, description lacks details on rate limits, authentication, or immediate delivery behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two paragraphs plus a tip. It is mostly clear but could be slightly more concise. The important tip is well highlighted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, and description does not explain what the tool returns (e.g., sent message object). Lacks details on error cases and response format for a complex mutable action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so the schema already documents most parameters. Description adds little beyond the tip about email addresses. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sends a message, can use JSON or MIME format, and mentions attachment capability. Distinguishes itself from creating a draft by offering that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on JSON vs MIME usage (attachments vs saving to Sent Items) and gives a critical tip to use list-users for recipient addresses. However, it does not explicitly differentiate from other send-related sibling tools like send-draft-message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the description's mutation nature is consistent. It adds the behavioral constraint that the default calendar's name cannot be updated. It does not disclose permission requirements or reversibility, but the annotation covers the destructive aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose. The tip provides an example and a caveat without fluff. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward update operation with strong schema coverage. The description gives a concrete example and a key limitation, but does not mention return values or side effects. Given the absence of an output schema, a brief note on response behavior would improve completeness, but the current level is adequate for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, already documenting most parameters. The description adds an example body ('{ name: 'New Name', color: 'lightBlue' }') and the constraint on default calendar name, providing practical usage context. No deeper param semantics are added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update a calendar' and 'Updates a calendar's properties,' clearly identifying the verb and resource. It distinguishes from sibling tools like update-calendar-event by targeting calendar-level properties. The example body further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying calendar properties via the example body. It notes the constraint 'Cannot update the default calendar's name,' which is a usage exclusion. However, it does not explicitly mention alternatives or when to use this tool versus other update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond the annotations: the requirement for an If-Match header and the meaning of priority values. Annotations already flag destructiveHint: true and readOnlyHint: false. However, it does not disclose whether the update is partial or full, or what happens to unspecified fields, which is a gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a tip. It is front-loaded with the core purpose and then provides critical usage details. No extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, 6 parameters, no output schema), the description covers a key prerequisite (ETag) and priority values, but is incomplete. It does not explain the return format, the behavior of partial updates, or how to choose this tool over sibling planner tools. Additional details about the response or update semantics would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 83%, most parameters are already described. The description adds value by explaining the If-Match header requirement and priority value mapping, but these are partially covered in the schema for priority. The body parameter lacks additional semantic information that could help agents understand partial update behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update the properties of plannerTask object.' This provides a specific verb and resource. However, it does not explicitly differentiate from sibling tools like create-planner-task or get-planner-task, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a critical tip about the required If-Match header and how to obtain the ETag, which is essential for successful use. It also enumerates the priority value mappings. However, it lacks guidance on when to use this tool versus alternatives, such as when to create a new task or delete one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true and readOnlyHint: false. The description adds a payload example but does not elaborate on side effects, permissions, or the actual creation process. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (one sentence plus a tip) and front-loaded. No extraneous text, though the tip could be integrated more concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and nested objects. The description covers the basic purpose but omits details about return values, error scenarios, or required permissions. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (80%), and the description adds value by showing an example body structure with 'displayName'. This clarifies the expected content beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'onenoteSection', specifying 'in the specified notebook'. It distinguishes from sibling tools like 'create-onenote-notebook' and 'create-onenote-section-page' through the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., when to use a section group). The tip provides an example body but does not clarify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description doesn't need to repeat that. The description adds a useful behavioral note: the body must be a full HTML document or it fails silently. However, it doesn't disclose other potential side effects or error states beyond the tip. Overall, minimal extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating purpose plus a tip about the body parameter. No unnecessary words, front-loaded with key information. The tip is formatted clearly with an emoji for attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema, the description provides the essential inputs (section, body) and a critical constraint (full HTML). It does not mention return values or whether the operation is idempotent, but those are not strictly required. The tip about silent failure is valuable. Overall, sufficiently complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly clarifies that the 'body' parameter must be a full HTML document, which is critical and not obvious from the schema alone. Schema coverage is 80%, so the description compensates with this key detail. Other parameters like 'onenoteSectionId' are well-described in the schema, so no further info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new page in a specified section. The verb 'Create' and resource 'page in specified section' are explicit, and the tool name reinforces this. It distinguishes from sibling 'create-onenote-page' which likely creates a page without specifying a section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'create-onenote-page' or 'create-onenote-section'. No mention of prerequisites or when not to use it. The tip about HTML body is helpful but does not address usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, but description reinforces permanence ('cannot be undone'), adding clarity beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. Front-loaded with the purpose and a concise tip. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple permanent delete operation, the description is adequate. It explains the action and permanence. No output schema exists, so no need to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description adds no extra parameter-specific meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a OneNote page' clearly, specifying the verb and resource. It distinguishes from siblings like 'delete-onedrive-file' by naming the specific resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other delete operations (e.g., delete-onedrive-file, delete-calendar-event). No exclusion criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true and readOnlyHint: false. The description adds behavioral context beyond annotations by disclosing the requirement for the If-Match header and ETag, which is critical for correct invocation. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: the action and a critical tip. It is front-loaded with the purpose and includes structured formatting with a tip indicator, earning its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and no output schema, the description covers the key prerequisite (If-Match header with ETag) which is essential for correct operation. It does not explain return values or side effects, but the tip provides sufficient context for a simple delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 5 parameters (100% coverage), so baseline is 3. The description itself does not add additional meaning for parameters; the tip mentions If-Match and includeHeaders but these are already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete plannerBucket.' uses a specific verb and resource, clearly stating the tool's action. It distinguishes from sibling tools like get-planner-bucket, update-planner-bucket, and create-planner-bucket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a critical tip about requiring the If-Match header with ETag from get-planner-bucket, which is a prerequisite. However, it provides no guidance on when to use this tool versus alternatives (e.g., when to delete vs. update) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it operates on the signed-in user's calendars and works for any calendar, which is useful context, but it does not disclose return format, error behavior, or other side effects. This is acceptable given the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences: the first states the core action and addressing, the second clarifies default calendar inclusivity. No fluff or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with a rich schema (9 parameters all described), the description is sufficient to understand the main purpose and scope. It lacks details about return values or error cases, but the absence of an output schema is not a critical gap given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description merely reiterates that calendarId and eventId are used for addressing, which adds no new meaning. Baseline of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get a single event'), a clear resource ('calendar event'), and the addressing method ('by calendar ID and event ID'). It also notes that any calendar, including the default one, can be addressed, which helps distinguish it from simpler event tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you have a calendar ID and event ID) and notes that it works for any calendar including the default. However, it does not explicitly contrast with sibling tools like get-calendar-event, leaving some ambiguity about when to choose one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the property is nullable and explains the content of permissions (roles, grantedTo, link, inheritedFrom), providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence stating purpose plus a tip explaining return content. No redundant words, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return content (roles, grantedTo, link, inheritedFrom) but does not mention pagination or that it returns a collection. Given the tool's simplicity and annotations, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all 13 parameters are well-documented in the schema. The description does not add parameter-level insights beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and resource 'permissions on a file or folder'. It specifies the scope (sharing links, direct access, inherited) and distinguishes from sibling tools like delete-drive-item-permission or create-drive-item-share-link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies a read-only use case but does not state when not to use or mention related tools like delete-drive-item-permission for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, and the description adds 'Read-only' and details the returned table properties. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a tip, front-loading the purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the key properties of tables but could be more explicit about the required parameters and pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description does not add further parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Lists all named tables in a workbook' and specifies the properties returned. It distinguishes itself from sibling tools like list-excel-worksheets and get-excel-table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it lists tables and hints at using table names with other endpoints, but does not explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds context about default sort and expand capabilities but does not go beyond what annotations and schema provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but a bit verbose with the tip and explanation. It front-loads the main purpose but could be more concise by removing redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count and good schema coverage, the description provides sufficient context: purpose, default sort, expand options, and a relationship to a sibling tool. No output schema exists, but the description covers the key aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions expand with specific property names (sections, sectionGroups, etc.) but this is already detailed in the schema. No significant additional parameter meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve a list of sectionGroup objects' and explains what a section group is. It distinguishes from sibling tools by mentioning pairing with list-onenote-notebooks for a complete picture of the notebook structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a tip that this tool lists all OneNote section groups for the user, and explicitly recommends pairing with list-onenote-notebooks. It implies usage context but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds context about being from the default folder and filter/search limitations. It does not discuss rate limits, pagination behavior (though parameters hint at it), or authentication needs beyond 'signed-in user'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence conveying the core purpose plus a short tip. No redundant information. Front-loads the main action. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately covers the tool's purpose and provides important querying guidance. It does not detail the return structure (e.g., contact fields), but the parameter descriptions and tool name compensate. Slight gap for a comprehensive view.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 11 parameters. The description adds marginal value by explaining filter/search constraints but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a contact collection from the default contacts folder of the signed-in user.' It specifies the resource (contacts) and action (list). The broader scenario mention and tips distinguish it from sibling contact tools like get-outlook-contact or list-contact-folder-contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a tip on filter limitations and suggests using $search as an alternative. However, it does not explicitly guide when to use this tool over other contact-related tools (e.g., retrieving contacts from a specific folder). The tip is about querying technique rather than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, covering safety. Description adds that it returns linkedResource objects with specified fields, but no additional behavioral traits (e.g., rate limits, auth requirements). Adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a tip. No unnecessary words. Main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions response fields (displayName, webUrl, etc.) and includes a tip. It covers the essential context for a list tool, though pagination or response structure details are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 13 parameters. The description adds no new parameter information beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves linked resources for a To Do task, listing fields like displayName, webUrl, etc. It is distinct from sibling tools (create/delete). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (list linked resources of a task) but no explicit guidance on when to use vs. other tools, nor when not to use. The tip provides context but lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's mention of 'sharing invitation' is consistent. The description adds the detail that an email can optionally be sent, but does not disclose other behavioral traits such as whether existing permissions are replaced, what happens on conflicts, or authorization requirements. With annotations covering the destructive nature, the description adds minimal additional behavioral context beyond the email note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph followed by a tip, totaling about three sentences. It is front-loaded with the main action and efficiently conveys purpose and key usage hints. However, the tip could be integrated more seamlessly, and the description could be slightly more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, nested objects, and no output schema, the description covers the main action, provides an example body, and explains roles. However, it lacks details on what the response contains (since no output schema exists), error conditions, prerequisites, or the effect on existing permissions. A more complete description would include expected return value or common errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), providing descriptions for many parameters. The description's tip adds value by providing a concrete example of the body (e.g., { recipients: [{ email: 'user@example.com' }], roles: ['read'] }) and clarifying the roles list. While the schema already defines roles and recipients, the example makes usage more intuitive. This goes beyond the schema's structural definitions, justifying a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a sharing invitation for a driveItem. It distinguishes from sibling tools like create-drive-item-share-link (which creates a link) and list-drive-item-permissions (which lists permissions). The verb 'Send a sharing invitation' with the resource 'driveItem' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a tip with an example body and role guidance, implying usage for sharing with specific users. However, it does not explicitly state when to prefer this tool over alternatives (e.g., creating a share link) or when not to use it. The tip provides some guidance but lacks explicit exclusions or context for alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the description does not need to emphasize destructiveness. It adds behavioral context about proposing new times and response options. The description aligns with annotations, no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two paragraphs and a tip bullet. It is well-structured and front-loaded, but the tip section could be more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers the main action and optional features. However, it does not mention what the response contains or any potential errors (beyond confirm gating).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%). The description adds value for the proposedNewTime parameter by showing its structure, but other parameters (confirm, includeHeaders, excludeResponse) are not elaborated in the description beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Tentatively accept the specified event in a user calendar.' It uses a specific verb and resource, and it distinguishes itself from siblings like accept-calendar-event, decline-calendar-event, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the proposedNewTime parameter and includes a tip with example usage. However, it does not explicitly state when to prefer this tool over related tools (e.g., accept-calendar-event) or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool updates a field (non-destructive), but the annotation destructiveHint: true marks it as destructive. This contradiction misleads the agent about the tool's safety. Description provides no detail on destructive aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the main action and uses a tip for examples. It is slightly verbose but structured effectively. Could trim redundant statements like 'You cannot use PATCH to change any other fields' appearing twice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 5 parameters, nested objects, no output schema, and a confirm parameter for destructive operations. The description explains the purpose and limitations but does not cover the confirm parameter, response control (includeHeaders/excludeResponse), or the response format. Adequate but missing details for full autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (baseline 3). Description adds value by specifying the valid body values, clarifying that senderEmailAddress cannot be changed via this call, and providing guidance on the inferenceClassificationOverrideId parameter. This compensates for the remaining schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes the classifyAs field of an override, distinguishing it from sibling tools like create-focused-inbox-override, delete-focused-inbox-override, and list-focused-inbox-overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (only for changing classifyAs) and when to use alternatives: POST for display name changes, delete and recreate for SMTP address changes. It also notes what cannot be changed via PATCH.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats the action already implied by the name and annotations. It adds no new behavioral information (e.g., side effects, confirmation requirements, or data overwrite risks) beyond the existing destructiveHint. The only additional detail is the body format, which is parameter-related.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded. The tip is clearly separated and provides essential formatting information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The combination of schema descriptions (86% coverage) and the description's body format example covers the essential usage. However, it lacks guidance on distinguishing this from similar Excel write operations and does not mention the confirm parameter's purpose (which is in the schema) or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a concrete example of the body.values array and the constraint that each inner array must match the table's column count. This goes well beyond the schema's generic range description, making the parameter usage clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add Excel table rows' and 'Adds rows to a table.' It is specific to table rows rather than ranges, but it doesn't explicitly differentiate from insert-excel-range or other row manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (adding rows to a table) but does not mention alternatives or exclusions, so it doesn't fully guide selection among sibling Excel tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about color mapping and case sensitivity beyond annotations (readOnlyHint: false, destructiveHint: true, openWorldHint: true). However, the destructiveHint annotation seems inconsistent with creation, but the description does not contradict it directly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences plus a tipped paragraph. Information is front-loaded and no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing description of the return value (no output schema). It states it creates an object but doesn't indicate the response includes the created category. Adequate for basic use but incomplete for an agent needing to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema coverage, the description enhances the body parameter by mapping color enums to human-readable names and emphasizing uniqueness of displayName. It does not explain confirm, includeHeaders, or excludeResponse, but schema covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create an outlookCategory object in the user's master list of categories,' providing a specific verb and resource. It distinguishes from sibling tools like list-outlook-categories by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., list-outlook-categories or other create tools). The tip only explains the body format, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's addition of scope (all notebooks) adds some behavioral context. However, no other behavioral details (e.g., pagination, rate limits) are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: purpose and a helpful tip. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description covers the return type and scope. However, it lacks details like default ordering or pagination hints, but the schema fills some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 11 parameters have full descriptions in the schema (100% coverage), so baseline is 3. The description adds no additional parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of onenoteSection objects across all notebooks. It distinguishes from sibling 'list-onenote-notebook-sections' by specifying the scope (all notebooks vs. specific notebook).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool (list all sections) and points to an alternative for notebook-specific listing. No additional usage exclusions are needed for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by noting default behavior (hidden folders excluded) and a parameter to include them. No contradictions with readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes the operation's input but does not specify the response format or fields. With no output schema, more detail on what the 'folder collection' contains would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The main description only adds context about includeHiddenFolders. Baseline 3 applies as schema already covers semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get the folder collection under the specified folder,' explicitly identifying the verb and resource. Mentions the shortcut for top-level folders, distinguishing itself from sibling list-mail-folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage (child folders vs. top-level via shortcut) but no explicit when-not or alternative tools. Lacks explicit guidance on when to prefer this over list-mail-folders or list-mail-folder-messages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'Update' adds little beyond the annotation. It does disclose that the operation targets a single row and requires a column-count-matching array, which implies full-row overwrite, but it does not describe return behavior, error cases, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a clear one-sentence purpose followed by a focused tip. It front-loads the core intent and adds only the most essential detail about the request body, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 5 required, and no output schema, the description covers the core operation and body structure but omits workflow context such as how table/row IDs are obtained, what happens when the row index is out of bounds, or what the response contains. It leans on schema descriptions for path parameters, but the absence of output details is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has descriptions for path parameters and confirm flags, but the tool description adds crucial meaning for 'body' (which is an untyped object in the schema) by specifying '{ values: [[...]] } with one inner array matching the column count.' It also clarifies 'index' is zero-based, which the schema does not. This compensates for the schema's lack of body structure detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an Excel table row, specifying 'single row in a formal Excel table by zero-based row index.' This distinguishes it from sibling tools like update-excel-range or delete-excel-table-row by focusing on row-level updates in formal tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating a single row in a formal Excel table, and the tip elaborates on the expected body format. However, it does not explicitly contrast with alternatives (e.g., update-excel-range) or state when not to use it, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's mention of 'Update' is consistent but adds no new behavioral context (e.g., permissions, side effects, or whether updates are reversible). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a tip, with no extraneous words. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the common renaming use case but does not mention that other properties (e.g., isHidden) can be updated or warn about potential side effects (e.g., moving messages if parentFolderId is changed). The schema fills some gaps, but given the destructive nature, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, and the schema descriptions for parameters are detailed (e.g., mailFolderId usage, confirm gate). The tool description only adds the 'displayName' tip, which is marginal beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update the properties of mailfolder object' with a specific verb and resource. The tip about renaming via displayName distinguishes this from sibling tools like create-mail-folder, delete-mail-folder, and list-mail-folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: it explains a common use case (renaming) and advises using list-mail-folders to get the folder ID. However, it does not explicitly state when not to use the tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, which is consistent with creating a new folder. The description adds that the returned folder ID can be used with other tools, providing extra behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three sentences plus a tip), front-loaded with the main purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains that the returned contactFolder has an id usable with other tools, which is helpful. However, it doesn't fully specify the return object structure, but it's adequate for a simple create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), so the baseline is 3. The description adds a concrete example of the body format ('displayName': 'Sub-folder name') and mentions the 'parent id' for contactFolderId, providing marginal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a contact folder as a child of a specified folder, with an option to create under the user's default folder. It distinguishes from sibling 'create-contact-folder' by emphasizing the child relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells users to 'Use list-contact-folders to discover the parent id' and provides a tip about the body structure. It doesn't explicitly say when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true. The description adds that it creates under default folder or specified parent, and returns the created folder with id. However, it does not clarify the contradiction about parent folder usage, nor disclose any side effects beyond creation. The behavioral transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the main action, and includes a tip. Every sentence adds value, and there is no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, 4 parameters, no output schema), the description is incomplete. It only provides a minimal example for the body and does not explain the full body structure or the behavior of the confirm parameter. The tip briefly mentions return value, but more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so baseline is 3. The description adds a concrete example ('Body: { displayName: 'Family' }') which adds meaning beyond the schema's property descriptions. It does not elaborate on other parameters like confirm or includeHeaders, but those are already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new contact folder under the user's default contacts folder. It mentions it can also create as a child of any specified folder, but this is contradicted by the tip which recommends using create-contact-child-folder for sub-folders, creating ambiguity. Overall, the main purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (create top-level folder) and when to use an alternative (create-contact-child-folder for sub-folders). This helps the agent distinguish between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint true and readOnlyHint false, so the bar for additional disclosure is lower. The description adds useful context about the pre-authenticated upload URL and the optional body with conflict behavior, but does not elaborate on side effects, session lifecycle, or required permissions beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and uses a helpful tip icon to highlight the main use case. Every sentence adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary purpose, return value, and key usage scenario. With no output schema, it provides enough to understand the tool's behavior, though it omits details like session expiration or how to use the uploadUrl, which might be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), so parameters are largely documented in the schema. The description adds an example path and conflict behavior, but does not systematically explain each parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an upload session, with a specific use case ('For large file uploads (no size limit)') and the key output ('Returns a pre-authenticated uploadUrl for direct PUT of file bytes'). This distinguishes it from siblings like upload-file-content and create-mail-attachment-upload-session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when to use it ('For large file uploads') and provides the URL path pattern for new files. It does not explicitly mention alternatives or when not to use it, but the context implies it is for large uploads requiring a session rather than direct uploads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive (destructiveHint=true). The description adds critical behavioral context: deleting a seriesMaster deletes all occurrences, and recommends using instance ID for single occurrence cancellation. This goes beyond the annotations and is valuable for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one action sentence and one tip. It is front-loaded with the primary purpose and adds the most important caveat in a compact form. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description covers the key risk (seriesMaster deletion) and provides usage guidance. It does not mention return values, but those are not required given no output schema. Sibling differentiation is minimal, but the critical behavior is disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description does not add parameter details but the tip reinforces the meaning of eventId by mentioning instance ID. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete a specific calendar event' with a specific verb and resource. It distinguishes itself from generic deletion by emphasizing 'specific', but does not explicitly contrast with sibling tools like delete-calendar-event. The tip adds valuable context about seriesMaster behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip provides explicit guidance: to cancel a single occurrence, use the specific instance ID. It warns against deleting seriesMaster, which would delete all occurrences. This implies when to use this tool and what to avoid, though it does not name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only and non-destructive hints. Description adds valuable context: default property subset, how to retrieve non-default properties with $select, and support for extensions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, front-loaded with purpose, but includes some redundancy (e.g., mentioning $select twice). Could be more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description sufficiently explains what is returned (user object) and how to customize results. It covers key behaviors and parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed parameter descriptions. The description does not add significant new information beyond the schema, only reiterating $select usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Retrieve the properties and relationships of user object' with specific verb and resource. The tool is distinct from siblings as the only one for the current user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use the tool, but does not explicitly state when not to use it or mention alternatives. Implicitly covers usage via $select and extension details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by explaining that listing returns metadata while downloading requires a different endpoint. No mention of rate limits or auth beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: one sentence for purpose plus a short tip. No fluff, front-loaded, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with good annotations and full parameter documentation, the description is mostly complete. It lists return fields and covers pagination hints in the schema. Minor gap: does not explicitly state that response includes nextLink for pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema's parameter descriptions; it only includes a tip about downloading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state 'Retrieve a list of attachment objects' and list specific fields returned (id, name, contentType, size, isInline). Distinguishes from sibling 'download-bytes' by noting how to download raw bytes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes a tip directing to 'download-bytes' for downloading content, providing usage context. However, it does not explicitly state when to use this tool vs other attachment operations like add or delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and non-destructive. The description adds value by enumerating the fields present in a rule (displayName, sequence, isEnabled, etc.), but does not disclose other behavioral aspects like pagination or potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence and a short tip. Every sentence serves a purpose without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is no output schema, the description partially compensates by listing the fields included in the returned rule objects. It provides enough context for a list operation, though it could mention that the result is an array.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 12 parameters are already well-documented in the schema. The description adds minimal extra meaning beyond the tip about using the Inbox folder ID for the mailFolderId parameter, which is also covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all messageRule objects for a user's inbox. The tip specifies it lists rules for a mail folder, distinguishing it from sibling tools like create-mail-rule, update-mail-rule, and delete-mail-rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a helpful tip on using the Inbox folder ID obtained from list-mail-folders, giving clear context for typical usage. It does not explicitly state when not to use the tool, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns localeInfo objects with locale and displayName, which provides some behavioral context. However, it does not disclose additional traits like potential latency, rate limits, or whether results are cached. The openWorldHint annotation signals non-determinism, which is not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: 4 sentences plus a front-loaded tip. It immediately states the purpose, then adds context, and finally provides actionable guidance. No redundant phrases, and each sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return format (localeInfo objects). It also connects the tool to a real workflow (validating locale before updating settings). However, with 8 optional parameters, it does not guide which ones are relevant for this tool (e.g., filter/search may be unnecessary for a small list). Despite this, it is largely complete for a read-only list tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for all 8 parameters (top, skip, count, filter, etc.). The tool description does not add any additional parameter-level meaning beyond what the schema already provides. At high coverage, baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the list of locales and languages that are supported for the user.' It identifies the specific resource (locales/languages) and related context (mailbox server configuration, Outlook client language selection). This uniquely distinguishes it from sibling tools like list-supported-time-zones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'When setting up an Outlook client, the user selects the preferred language from this supported list.' It also advises to 'Use this to validate the locale value before calling update-mailbox-settings.' This gives clear context and a concrete scenario, though it doesn't explicitly mention when not to use the tool or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, so the description's mutation nature is clear. It adds context about the reauthorizationRequiredDateTime window and no-body requirement, but does not detail the exact outcome (e.g., subscription renewal). This is adequate but not highly informative beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only 4 sentences plus a tip. Every sentence adds value: purpose, timing, no-body requirement, and expiration window. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers the core usage scenario, including when to invoke and constraints. It could mention the return value (e.g., updated subscription) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. The description only adds 'No body required' which is implicit from the schema. Baseline 3 is appropriate as no significant additional parameter insight is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reauthorizes a subscription in response to a 'reauthorizationRequired' challenge, distinguishing it from subscription CRUD siblings like create-subscription or delete-subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: upon receiving a reauthorizationRequired challenge or notification. It also notes the 48-hour window and that no body is required, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, marking this as a write operation. The description adds context about which properties can be updated (e.g., isRead, flag, categories, importance) but does not disclose extra behavioral traits like side effects, required permissions, or rate limits. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and includes specific examples. Every part adds value; there is no waste. It is appropriately short and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, no output schema), the description covers the main use cases (updating message properties) adequately. It does not explain return values, but annotations and sibling tools provide context. Minor gaps: no mention of handling drafts vs sent messages, or partial updates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so most parameters are already documented. The description adds meaning by listing example updates (mark read, flag, change categories, etc.), which maps to some body properties. However, not all parameters (like confirm, includeHeaders) are covered in the description, and the body schema includes properties not mentioned (e.g., attachments, toRecipients).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (update) and the resource (existing Outlook email message), and provides specific examples like mark read/unread, flag, change categories, importance, edit draft's subject, body, or recipients. This distinguishes it from siblings such as send-mail, delete-mail-message, or create-draft-email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples of when to use the tool (update properties) but lacks explicit guidance on when not to use it or alternatives. For instance, it does not contrast with send-mail for sending or delete-mail-message for deletion. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true. The description adds context about overwriting without warning and the 4MB size limit. No contradictions, and the additional details help the agent understand the tool's impact beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a tip format to highlight key points. However, the first sentence is slightly awkward and could be more direct. Overall, it is efficient with no wasted verbiage, but structure could be improved slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value or output of the tool, which is absent from both description and output schema. For a file upload tool, the response format (e.g., file metadata) is important for agent decisions. Additionally, prerequisites like authentication are not mentioned, though annotations partially cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is well-described in the schema. The description adds global context (base64, size limit) but does not provide per-parameter insights beyond what the schema already offers. Thus, minimal added value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is for uploading file content, with the first sentence 'The content stream, if the item represents a file' indicating the resource. It clarifies overwriting behavior and distinguishes from the sibling 'create-upload-session' for large files. However, the first sentence is somewhat vague and could be more explicit about the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using 'create-upload-session' for files above 4MB, provides the path format for new files, and warns that the tool overwrites existing files without warning. This gives clear when-to-use and when-not-to-use guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context by stating 'does not send' and framing the action as a review step, which clarifies the tool's non-destructive nature beyond the destructiveHint annotation. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and contains no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested schema for body and messageId, the description provides a basic overview but does not explain how the forward draft is constructed or how messageId relates to the original message. It is minimally sufficient but relies on schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the parameters are well-documented in the schema. The description itself adds no additional parameter-specific meaning beyond the high-level purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a forward draft' with a specific verb and resource. The tip reinforces that it does not send, distinguishing this tool from forward-mail-message and send-mail siblings. This is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip 'Useful when user wants to review before sending' provides a clear context for use. It implies when not to use (when the user expects immediate sending), but it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false. Description adds that 'Outlook carries out those actions' but does not disclose additional behavioral details like permission requirements, error states, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences including a TIP and example. Front-loads purpose, then provides practical guidance. Concise but not overly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides a clear creation example and action list. Missing return value description (no output schema) but schema deeply covers inputs. Adequate for a creation tool with complex nested parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 80% coverage. Description adds a concrete body example with required fields (displayName, sequence, isEnabled) and enumerates possible actions (moveToFolder, delete, etc.), enhancing understanding beyond the schema's property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Create a messageRule object' with specific verb (create) and resource (messageRule). Differentiates from sibling tools like list-mail-rules or update-mail-rule by its creation focus. Also provides a TIP for using Inbox folder ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a TIP directing to get Inbox folder ID from list-mail-folders for inbox rules, providing essential context. However, does not explicitly state when not to use this tool (e.g., for updating existing rules) or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses beta status, auth restrictions, and the mutation nature (consistent with destructiveHint=true). It explains the body format, notes that no ETag is required, and warns of API changes. However, it does not describe the return value or potential side effects on the task's chat state. Still, it adds significant context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear purpose statement, a tip section with usage guidance, then parameter details, and finally limitations. It is slightly verbose but remains focused and front-loaded. Each section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (beta API, nested objects, auth restrictions), the description covers most aspects: what the tool does, when to use it, auth constraints, body format, and that no ETag is required. Missing are the return value (though no output schema) and mention of the confirm parameter for destructive ops. Overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (80%). The description paraphrases the body structure and mentions required parameters, but adds little beyond what the schema already provides. The confirm parameter is not mentioned in the description, though it is in the schema. Overall, the description adds marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create'), the resource ('plannerTaskChatMessage on a plannerTask'), and distinguishes it from sibling tools like list-planner-task-messages and delete-planner-task-message by specifying it's for creating a new message. It also contrasts with legacy comments, reinforcing its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it notes that task chat is the 'current supported way' and contrasts with the legacy comments experience. It also lists important usage constraints (delegated work/school accounts only, no personal accounts, global cloud only, beta API). However, it does not explicitly name sibling alternatives like 'list-planner-task-messages' or 'delete-planner-task-message' for when to use those instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. Description adds value by explaining expanded recurring instances, filtering features, and Teams meeting details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear tip section, though slightly verbose. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers expanded events, filtering, and Teams integration. Lacks explicit pagination behavior but schema covers pagination params. Adequate given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description reinforces required params but adds no significant new semantics beyond the tip.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves calendar view events with expanded recurring instances, and explicitly distinguishes from get-specific-calendar-view for non-default calendars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context and directs to get-specific-calendar-view for non-default calendars, with additional filtering tips. Could include when to use list-calendar-events instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read) and destructiveHint=false. The description adds behavioral details: pagination via @odata.nextLink, delta tokens, deleted facet, and the need to apply changes to local state. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but slightly verbose, with a separate tip section. It is well-structured using paragraphs and lists, front-loading the core process. Every sentence adds value, though some redundancy exists between the main description and the tip.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex delta tracking tool, the description covers the essential workflow: initial call, pagination, deltaLink, handling deleted items. No output schema exists, but the description adequately explains what to expect. It could mention rate limits or error handling, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds no new semantic meaning beyond the schema. Per guidelines, baseline is 3 when coverage >80%. The description does not enhance understanding of parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as tracking changes in a driveItem and its children over time, using delta tokens. It specifies the purpose with strong action verbs ('Track changes') and distinguishes it from siblings like get-drive-item or list-folder-files by focusing on incremental sync and delta queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a step-by-step usage pattern: start with no parameters, follow nextLink for pagination, then use deltaLink for future changes. The tip adds prerequisite guidance (get root driveItem first). It lacks explicit 'when not to use' but gives clear context for proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. Description adds context about default omission of nested properties and the meaning of cell styling, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a tip, front-loaded with purpose. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so understanding return structure relies on description. Description lists some properties but is vague on the full format object. Missing details about error conditions or prerequisites like valid address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but the description adds value by explaining the expand parameter in context (nested font, fill, borders omitted by default) beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns a format object' for a range and specifies it is read-only. This distinguishes it from sibling tools like format-excel-range which modify format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip implies usage for reading format and explains how to expand nested properties, but does not explicitly mention when not to use it or suggest alternatives like format-excel-range for writing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. The description adds that it returns the MIME stream as text including headers/attachments, which is useful but not exhaustive (e.g., no mention of size or pagination risks).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a tip, front-loaded with core action, no redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core action and use case but lacks details on error handling, permissions, or size warnings for fetchAllPages. No output schema, so more context on return format would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter-level detail beyond what's already in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads raw MIME source of an Outlook email by message ID, specifies the output (complete headers and attachments), and distinguishes from related tools like list-mail-messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip gives a specific use case (archiving email to disk) and mentions prerequisites (find message with list-mail-messages). However, it does not explicitly contrast with get-mail-message or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. Description adds value with behavioral details: expanded recurring instances, seriesMasterId/type fields, and Teams joinWebUrl requirement, making actual behavior clearer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence and packs the TIP with actionable details. It is somewhat long but every clause adds practical value, and the emoji/bullet style keeps it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters and no output schema, the description covers the essential usage patterns, required parameters, pagination, and Teams-specific behavior. It doesn't fully describe the response shape, but for a list operation with rich param schemas, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reinforces ISO 8601 format and adds a filter hint for Teams meetings, but most parameter semantics are already fully documented in the schema; no major compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' with clear resource: occurrences/exceptions/single instances of events over a time range from a specific calendar by ID. It explicitly distinguishes from alternatives by noting it returns expanded recurring event instances (not just seriesMaster), differentiating it from sibling calendar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives practical context: required start/endDateTime in ISO 8601, fetchAllPages for many events, and $filter=isOnlineMeeting eq true for Teams meetings. It does not explicitly name alternative tools for when not to use it, but the 'specific calendar' scope implies the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and non-destructive. The description adds value by explaining that the response includes id, displayName, and parentFolderId, and that OData query parameters are supported. It also notes that the built-in 'Contacts' folder is always returned, which is helpful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear main sentence followed by a helpful tip section. It is front-loaded with the primary purpose and avoids verbosity, though it could potentially be slightly shorter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately specifies the returned fields and mentions OData support. It provides sufficient context for an agent to understand the tool's output and usage, though additional details about pagination behavior could be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the baseline is 3. The description mentions OData query parameters in a tip but does not provide detailed semantic meaning beyond what the schema already offers. It adds minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the contact folder collection from the default Contacts folder of the signed-in user. It specifies returned fields (id, displayName, parentFolderId) and distinguishes from sibling tools like list-contact-folder-contacts and create-contact-in-folder by noting that this tool is used to discover folder IDs before using those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool before list-contact-folder-contacts or create-contact-in-folder to obtain folder IDs. It also notes the built-in 'Contacts' folder is always included. However, it does not explicitly state when not to use this tool, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds behavioral context: returns empty for unsupported types, short-lived URLs, and the specific sizes and dimensions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main line and a clear tip section. It is concise but could be slightly trimmed without losing value. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the response structure (sizes, URLs, dimensions) and behaviors (empty for unsupported types, short-lived URLs). Pagination is covered by schema params. Lacks mention of potential pagination of thumbnail sets themselves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value beyond what the schema already provides for parameters. The general advice on $select and $expand is helpful but not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists thumbnailSet objects for a file, specifies the three sizes (96px, 176px, 800px) with url and dimensions, and distinguishes itself from other drive tools by focusing solely on thumbnails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use the tool (to retrieve thumbnails) and includes tips on using $select and $expand, as well as noting unsupported types. However, it does not explicitly mention when to prefer alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds value by explaining that an empty collection is returned if no overrides exist, and details the override structure. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and uses a tip to highlight key details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description fully explains the return structure (id, classifyAs, senderEmailAddress) and notes pagination by mentioning initial empty state. It is complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description need not add parameter details. The description does not provide additional semantics beyond what the schema already conveys, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves overrides that classify messages from specific senders, and distinguishes from sibling tools like create/update/delete-focused-inbox-override. It also details the structure of each override (id, classifyAs, senderEmailAddress).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly advise when to use it versus alternatives like search or other list tools. It provides clear context but lacks exclusions or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and non-destructive. Description adds that delegates/share recipients get empty response, which is critical behavioral info. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with main purpose and includes a tip. Slightly verbose but each sentence adds value (e.g., empty collection note, object structure). Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description must explain return values. It details object fields and notes empty response case. For 11 parameters and no output schema, it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description does not add extra semantic meaning beyond the schema, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists permissions of users with whom the calendar is shared. It differentiates from sibling tools like create/update/delete calendar permission and specifies it returns calendarPermission objects with detailed fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes guidance that it works on primary calendar, returns empty for delegates/share recipients, and mentions non-primary calendar is not exposed. Lacks explicit alternative tool names but provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds important behavioral details: beta API status, no application permissions, no personal accounts, global cloud only, and lists the content of each message. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. The first sentence clearly states the purpose, and the tip is helpful. Slightly more could be trimmed, but overall it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return value structure (fields like id, content). It also covers limitations and prerequisites. The number of parameters (12) is high, but schema covers them fully, so the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant parameter meaning beyond what is already in the schema, though it does mention beta constraints not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of plannerTaskChatMessage objects for a plannerTask, using a specific verb ('Retrieve') and resource. It also distinguishes itself from legacy conversationThreadId comments, which helps differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a tip indicating the modern task chat context vs legacy comments, giving some guidance on when to use this tool. However, it does not explicitly state when not to use it or compare with other tools like get-planner-task-details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and destructiveHint. Description adds context: response content depends on context, lists typical returned properties, and explains that no dedicated Subscription scope exists, requiring inherited permissions. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with the main purpose. Includes a tip and important permission note without being overly verbose. Could be slightly tighter but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists expected fields and notes dependency on app context. Covers permission and filtering guidance. Lacks explicit mention of pagination handling via @odata.nextLink, but that is covered in schema parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with detailed parameter docs. The description adds overall context (filtering, pagination tips) but does not significantly enhance individual parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves webhook subscriptions, specifying the basis (app ID, user, role) and distinguishes it from sibling tools like create-subscription and delete-subscription by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a tip on usage: lists subscriptions owned by current app/user, suggests filtering with $filter, and highlights permission requirements. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark destructiveHint=true. The description adds behavioral context by explaining that it creates a new copy and removes the original, which clarifies the destructive nature. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a helpful tip. Every sentence adds essential information, and the tip improves usability without excess verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and moderate schema coverage, the description explains the core action but lacks information about return values, error conditions, or prerequisites. Given the tool's simplicity, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%. The description adds value beyond the schema by noting that destinationId accepts well-known names (inbox, drafts, etc.), which is not in the schema. Other parameters are already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a message to another folder, creating a copy and removing the original. This specific verb-resource combination distinguishes it from siblings like copy-mail-message (which only copies) and delete-mail-message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., copy-mail-message). The tip about destinationId is helpful but does not address usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the essential ETag requirement and checklist format, adding value beyond the annotations (destructiveHint=true). It does not contradict annotations, and the concurrency control detail is a key behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a tip. Every sentence provides essential information, and the critical tip is front-loaded with 'CRITICAL'. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers key aspects (ETag, checklist), it omits information about the response structure or possible errors (e.g., ETag mismatch). Since there is no output schema, describing the return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 83% schema coverage, the description adds useful semantics: clarifies the If-Match parameter, checklist GUID format, and the correct usage of plannerTaskId (not as id). This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('plannerTaskDetails object'). This distinguishes it from sibling tools like 'update-planner-task' which updates a different object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a critical prerequisite (If-Match header from get-planner-task-details) but does not provide explicit guidance on when to use this tool versus alternatives like update-planner-task. The context is clear but lacks when/when-not logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, so the description's mention of creating and updating overrides aligns with this. The description adds context about the update behavior (renaming a sender) and the required body structure, going beyond the annotation hints. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, starting with the primary purpose. It includes a tip and important notes without being overly verbose. The structure is logical, though some redundancy (e.g., the tip repeats the body format) could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, required fields, update behavior, and address resolution. However, it does not mention what the response looks like after creation, error cases, or permissions. Given no output schema, more detail on return values would be beneficial. The openWorldHint annotation allows some leeway.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 75% of parameters. The description adds a concrete example of the body object (classifyAs and senderEmailAddress with fields) and specifies that classifyAs must be 'focused' or 'other'. This provides practical guidance beyond the schema's enum definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Focused Inbox override for a sender identified by an SMTP address, specifying that future messages will be consistently classified. The verb 'create' and resource 'focused-inbox-override' are specific, and the tool is distinct from siblings like 'create-draft-email' or 'create-planner-task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it tells the agent to resolve the sender's address using list-users or recent mail headers, and explains that if an override already exists, the POST updates it. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and potential destructiveness (destructiveHint=true), so the description does not need to repeat that. It adds the nuance that 'isHidden' can only be set on creation, but does not disclose other behavioral traits like error handling or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a tip, with no wasted words. It is front-loaded with the primary purpose and immediately actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema, the description does not explain the return value or error conditions. However, given the complexity of the input schema, the tip provides essential context about finding the parent ID, making it fairly complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 80% schema description coverage, the schema already documents most parameters. The description adds value by highlighting the 'isHidden' property must be set on creation and providing the tip about parent folder ID, though it does not cover all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'create a new child mailFolder' and 'Creates a subfolder inside an existing mail folder,' which provides a specific verb and resource. It distinguishes itself from sibling tools like 'create-mail-folder' by explicitly specifying it is for child folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a tip to use 'list-mail-folders' or 'list-mail-child-folders' to find the parent folder ID, guiding proper usage. However, it does not explicitly mention when not to use this tool or provide alternatives like 'create-mail-folder' for top-level folders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly and destructiveHint. The description adds behavioral insight about isHidden being settable only on creation, but lacks further context on side 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a tip. Front-loaded with purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers creation context and cross-references siblings well. Lacks output description but matches tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (75%), so baseline is 3. The description adds a tip about isHidden, but the schema already describes most parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new mail folder in the root folder, distinguishing it from the sibling tool create-mail-child-folder for subfolders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use this tool (top-level folder) and when to use alternatives (create-mail-child-folder for subfolders, list-mail-folders to find IDs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, consistent with the creation action. The description adds valuable context beyond annotations: it mentions required read permissions, expiration time limits, and validation token requirements, which are not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a tip section and front-loaded purpose. While somewhat lengthy, it avoids redundancy and each sentence adds value. The use of bullet-like formatting in the tip aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key aspects: purpose, required fields, permissions, and expiration limits. However, it does not explain the return value (the created subscription object) or error conditions, which would be helpful given the complexity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by summarizing required parameters (changeType, notificationUrl, resource, expirationDateTime, clientState) and providing examples like '/me/mailFolders/inbox/messages'. It also explains optional fields like includeResourceData, which is not covered in schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool subscribes a listener to receive change notifications for a specified resource in Microsoft Graph. It uses specific verbs ('subscribes', 'create') and distinguishes it from siblings like 'get-subscription', 'update-subscription', and 'delete-subscription'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to receive change notifications) and includes a tip summarizing required fields. However, it does not explicitly state when not to use it or name alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true. The description adds that it creates a task and lists optional fields, but does not elaborate on potential side effects, permissions required, or constraints (e.g., rate limits). The added value beyond annotations is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a concise tip, no wasted words. The purpose is front-loaded, and the tip provides essential usage guidance efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the creation operation, required parameter source, and optional fields. No output schema exists, so the description does not detail return values, but it implies the created task object. Given the complexity of the input schema, the description is adequate but could mention the response structure more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so baseline is 3. The description adds value by summarizing key optional fields (dueDateTime, reminderDateTime, etc.) and explaining the source of todoTaskListId. This helps the agent understand common usage patterns beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new task object in a specified todoTaskList,' providing a specific verb and resource. It distinguishes from siblings like update-todo-task and delete-todo-task by using 'create' and specifying the required list ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip explicitly states the need for 'todoTaskListId from list-todo-task-lists,' offering clear context for prerequisites. However, it does not explicitly state when not to use this tool or provide alternatives for similar tasks (e.g., adding tasks to Planner).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true. The description adds value by specifying that all events within the calendar are deleted and that the action is irreversible. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a tip. The purpose is front-loaded in the first sentence, and the tip adds essential behavioral context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description provides key constraints (non-default calendar only, irreversible) and hints at the confirm parameter (though not detailed). Could mention required permissions, but overall complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not add parameter information beyond the schema. Baseline of 3 is appropriate as the schema already documents all parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a calendar other than the default calendar' and adds a tip that it deletes all events. It distinguishes itself from sibling tools like delete-calendar-event by specifically targeting calendar deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that the default calendar cannot be deleted, providing a clear exclusion. The irreversibility warning guides appropriate use. However, no direct comparison to alternative tools like update-calendar or delete-calendar-event is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it explains that deleting a meeting sends cancellation to attendees and warns about seriesMaster deletion. Annotations already indicate destructiveHint=true, so the description enriches with specific effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a separate tip, all directly relevant. No wasted words, and the critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and presence of annotations (destructiveHint) and full schema coverage, the description covers key behavioral aspects (cancellation, recursion) adequately. No output schema is needed as return is standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds minimal extra meaning, only hinting that eventId should come from the event's 'id' field. This provides slight additional value, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses clear verb 'Removes' and specifies the resource 'event from the containing calendar'. It also distinguishes behavior for meeting cancellation and recurring events, setting it apart from siblings like 'cancel-calendar-event' or 'delete-specific-calendar-event'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a tip about deleting seriesMaster vs single occurrence, which guides usage. However, it does not explicitly state when to use this tool versus alternatives like 'cancel-calendar-event' or 'delete-specific-calendar-event', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds that only a single row is affected and that the index is zero-based, which is useful. However, it does not disclose additional behavioral details such as irreversibility or index shifting after deletion. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two sentences. The key action and the clarifying tip are both front-loaded and add value without fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward destructive row deletion. The description covers what it does and the critical index semantics. The schema covers all parameters, and annotations cover the safety profile. The description could mention consequences like row shifting, but that is not essential given the schema and annotations. Overall, it is adequately complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with property descriptions, so baseline is 3. The description adds meaningful semantic value by clarifying that the 'index' parameter is zero-based, which is not present in the schema's description ('Value for the index path segment'). This helps the agent correctly interpret and invoke the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an Excel table row' and further specifies 'Delete a single row from a formal Excel table by zero-based row index.' This is a specific verb+resource description that distinguishes the tool from sibling tools like delete-excel-range or list-excel-table-rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for deleting a single row from a formal Excel table and emphasizes the zero-based index. It does not explicitly exclude alternatives, but the specific wording implies when this tool is appropriate versus related tools. No explicit 'when not to use' guidance, but enough context to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond annotations: irreversible deletion of all contents. It aligns with destructiveHint=true and readOnlyHint=false. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences and a tip. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function, irreversibility, and how to find folder ID. With no output schema and full input schema coverage, it is largely complete, though parameter details are left to schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds limited value. It mentions specifying folder ID or well-known name, which is helpful but does not elaborate on other parameters like If-Match or includeHeaders.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete the specified mailFolder' and specifies the resource type, including support for mailSearchFolder. It distinguishes itself from sibling delete tools by focusing on mail folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip 'This action is irreversible' and suggestion to use list-mail-folders provide clear guidance on when to use and prerequisites. However, it does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description confirms deletion. It adds behavioral details beyond annotations: no request body, conditional deletion via If-Match, 204 response, and account restrictions. It could mention if the deletion is permanent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a tip. The purpose is front-loaded, and every sentence adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the return (204) and constraints (BETA, account type). It also mentions the conditional deletion behavior. It is complete enough for the agent to understand usage and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters. The description adds minimal extra parameter context (e.g., mentioning If-Match optionality again). Baseline 3 is appropriate as the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with "Delete a plannerTaskChatMessage object," clearly stating the verb (delete) and resource (plannerTaskChatMessage). It distinguishes from siblings like list-planner-task-messages and create-planner-task-message by specifying the delete action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important usage constraints: BETA API, delegated work/school accounts only, no application permissions, no personal Microsoft accounts, global cloud only. It also gives tips about no request body, optional If-Match, and 204 return. However, it does not explicitly compare with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint: true and readOnlyHint: false. The description adds that the method saves the message in the Sent Items folder, which implies sending. It also mentions HTTP 400 errors for invalid combinations. This adds useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and a tip, making it easy to scan. It is informative but slightly verbose; a few sentences could be trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (two formats, nested objects) and no output schema, the description covers the main use cases and constraints. However, it does not explain the return value or confirm that the forwarded email is sent immediately. The tip implies server-side handling but is vague. It could be more complete about outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the baseline is 3. The description adds significant value by explaining parameter constraints: specifying both comment and body returns 400, toRecipients is required, and toRecipients can be in the parameter or in the message object. It clarifies usage of key parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forwards a message using JSON or MIME format, with specific verb and resource. It distinguishes from creating a draft by mentioning 'Alternatively, create a draft to forward a message, and send it later.' The tip also reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance for JSON vs MIME formats, including constraints on parameters like comment/body and toRecipients. It also mentions the alternative of creating a draft. However, it does not explicitly compare to other sibling tools like send-mail or reply-mail-message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's mention of included fields (subject, sender, etc.) adds useful behavioral context without contradiction. It does not detail all response elements but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences, front-loaded with the action ('Get a single Outlook email message...') and includes a helpful usage hint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description outlines the key response fields and prerequisite step. It relies on schema descriptions for parameters, which is acceptable. A mention of pagination or expand behavior would improve completeness but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no new parameter details beyond referencing 'messageId' indirectly. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single Outlook email message by its ID, listing key fields included (subject, sender, recipients, body, attachment flags). It implicitly distinguishes from sibling tools like 'list-mail-messages' and 'get-mail-message-mime'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use 'list-mail-messages' first to obtain the message ID, providing clear usage context. However, it does not explicitly mention when not to use it or alternatives beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. Description adds context about response containing @odata.etag, which is important for update/delete operations. No contradiction. Behavioral traits beyond annotations are minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a tip, front-loaded with main purpose. Every sentence contributes value; no wasted words. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description mentions properties and relationships. The ETag tip adds important context for follow-up operations. Given 6 parameters and 1 required, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; each parameter has a description in the schema. The tool description does not add additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve the properties and relationships of a plannerBucket object.' Verb (retrieve) and resource (plannerBucket) are specific. Distinct from siblings like create-planner-bucket, update-planner-bucket, delete-planner-bucket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a tip about @odata.etag required for update/delete and suggests using includeHeaders=true. Provides context for subsequent actions. Could be improved by explicitly stating when not to use, but the tip adds value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by revealing that the response includes @odata.etag and that it's required for update, and suggests using includeHeaders to capture it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action, followed by a helpful tip. It is efficient but could be more structured with a separate example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters fully described and no output schema, the description could be more explicit about the return value shape. It mentions etag but lacks details about other properties returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a tip about includeHeaders that provides extra context beyond the schema, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Retrieve' and the resource 'plannerTask object'. It distinguishes from sibling tools like update-planner-task (update) and get-planner-task-details (details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip about using includeHeaders to capture etag for update-planner-task gives context for when to use this tool. However, it does not explicitly exclude alternatives like get-planner-task-details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds return field details (resource, changeType, notificationUrl, expirationDateTime, applicationId) and mentions the Permissions section, enhancing transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two parts: a clear purpose sentence and a useful tip. Front-loaded with key action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by listing key return fields. It mentions permissions reference. Could include pagination or error handling, but overall adequate for a simple get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add parameter-specific details beyond the schema, but the tip lists return fields which provide context for output expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve the properties and relationships of a subscription' and the tip specifies 'Gets a specific webhook subscription by id'. It distinguishes from sibling list-subscriptions by focusing on a single subscription by id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip advises 'Use list-subscriptions to find the id', providing clear prerequisite guidance. It implicitly indicates when to use this tool (when you have a specific id) but does not explicitly exclude alternatives like create or update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive hint (destructiveHint=true) and readOnly hint false. The description adds that responses are returned in arbitrary order and must be matched by id, which is useful. However, it does not elaborate on authorization needs or rate limits beyond what annotations provide, supplying only moderate added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clearly structured and front-loaded with the core purpose. The repeated 'tip' block adds some redundancy but reinforces key information. Overall, it is efficient and well-organized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, no output schema, and nested objects, the description thoroughly covers return format (responses with id, status, body, headers), arbitrary order, matching by id, URL relativity, and three use cases. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers 75% of parameters with descriptions, the 'body' parameter has no schema definition but is richly detailed in the description with examples and structure. The description compensates for schema gaps, adding meaning about the complex body format, depensOn, and headers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Combine up to 20 Graph requests into a single HTTP call' with a specific verb and resource. It clearly differentiates from sibling tools which are individual Graph operations, making its unique batching purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides three concrete use cases (parallelize reads, sequence dependent writes, batch writes) and a critical note about URL relativity. However, it does not explicitly state when not to use it (e.g., for single requests) or compare to alternatives, but the context of siblings implies when batching is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about folder selection but does not disclose additional behavioral traits beyond what annotations and schema provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a tip, front-loading the main purpose. Every sentence adds value with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema covering parameters, the description is adequate: it identifies scope, distinguishes from siblings, and lists OData supports. However, it lacks explicit mention of return structure or pagination, which the schema partially covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description does not add new meaning to parameters beyond listing supported OData features, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets contacts from a default or specified folder, and explicitly distinguishes itself from the sibling tool list-outlook-contacts, which only returns contacts from the default folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance to pair with list-contact-folders to get the folder ID, contrasts with list-outlook-contacts for default folder, and lists supported OData parameters, indicating when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms read-only behavior, matching the readOnlyHint annotation. It adds context that rows have index and values, and mentions pagination. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence and a tip. No filler, front-loaded with key information. Every word is earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 14 parameters and no output schema, the description is brief but the schema parameters are thoroughly documented. The description could explain return value structure more, but the tip provides enough context for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description does not add significant parameter semantics beyond the schema; the tip briefly mentions $top and $skip but adds little new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all rows in a table and is read-only, distinguishing it from sibling tools like add-excel-table-rows or update-excel-table-row. The verb 'list' and resource 'excel-table-rows' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip provides guidance on pagination with $top and $skip, but does not explicitly state when to use this tool versus alternatives (e.g., get-excel-range for a specific range). However, the schema parameter descriptions offer additional usage hints like starting with small $top.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and non-destructive behavior. The description adds behavioral details such as the default exclusion of hidden folders and the limitation to root children, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, each adding distinct information. It is front-loaded with the core purpose and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clarifies the return structure (collection under root, includes search folders, excludes hidden). Parameters are well-documented in the schema, covering pagination and filtering context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The tool description adds only minor context (mentioning includeHiddenFolders), so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves mail folders directly under the root folder, includes search folders by default, and excludes hidden folders. This specificity distinguishes it from siblings like list-mail-child-folders which operate on an arbitrary parent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use includeHiddenFolders and notes that this operation does not return all folders, requiring traversal for full mailbox. However, it does not directly contrast with similar siblings like list-mail-child-folders or list-mail-folder-messages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: the task list id is needed for tasks, the default list is 'Tasks', and $select is unsupported. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short sentences plus a TIP and NOTE. The main purpose is front-loaded, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters but full schema coverage and no output schema, the description sufficiently explains the output (list of objects with properties) and the key return value (id). It is complete enough for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions. The tool description itself does not add significant new meaning to the parameters beyond noting the $select restriction. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a list') and the resource ('todoTaskList objects and their properties'). It also adds a TIP that it returns the id needed for all task operations, distinguishing it from other todo tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (to list task lists and get the id) and includes a warning about $select not being supported. However, it does not explicitly mention when not to use it or compare with alternatives like 'get-todo-task'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate safety. It adds the note about combining move and rename in one request, but doesn't disclose potential side effects like overwriting, path updates, or failure modes. This is minimal additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, the first states the core purpose and the second is a compact tip. It is front-loaded, scannable, and every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a large input schema and no output schema, the description covers the essential operations (move, rename, or both) with clear parameter guidance. It could say more about error cases, cross-drive moves, or permission requirements, but the basic usage is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so the baseline is 3. The description adds value by explicitly mapping parentReference.id to the move action and 'new name' to rename, which clarifies the semantic intent beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Move or rename a OneDrive item,' which clearly states the verb, resource, and operation. It distinguishes itself from siblings like copy-drive-item and delete-onedrive-file by explicitly naming move/rename rather than copy or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit instructions: provide parentReference to move and new name to rename, and notes both can be done in a single request. It doesn't explicitly contrast with alternatives, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It reveals the action removes from cache (non-destructive to cloud service), but lacks details on required permissions, side effects, or reversibility. This is adequate for a simple tool but leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The action and target are front-loaded, and the sibling reference is helpful. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the key aspects: purpose, input format, and discovery of available accounts via list-accounts. Could mention login requirement or cached state, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a good description. The tool description adds an example (user@outlook.com) and clarifies accepted formats (email or ID), providing additional meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'Microsoft account from the cache'. It specifies accepted input formats (email or account ID) and distinguishes from siblings like logout and delete-onedrive-file by specifying 'from the cache'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using list-accounts to discover available accounts, providing clear context for when to use this tool. However, it does not explicitly contrast with similar actions like logout or deleting an account from the service.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as destructive, and the description adds behavioral detail that the operation targets 'any merged cells' and reverts them 'back to individual cells.' It also states 'No request body,' which is useful. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences plus a tip. Every sentence adds value: it states the action, clarifies the scope, notes the request body requirement, and references the sibling tool. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the schema's full parameter coverage, and the destructive annotation, the description is largely adequate. It could add a note about data retention (e.g., which cell value is kept), but that is a minor gap. The 'inverse' relationship and the scope of the operation are clearly communicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% descriptions for all parameters, including confirmation gates and ID guidance. The description adds no additional parameter-level meaning beyond a global 'No request body' note, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Unmerge an Excel range' and elaborates 'Unmerge any merged cells within the given range back into individual cells.' It also explicitly distinguishes this from the sibling tool by calling itself the 'Inverse of merge-excel-range,' which is a strong differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by noting this is the inverse of merge-excel-range, implying when to use it. It also adds the practical note 'No request body.' However, it does not explicitly state when not to use it or mention other alternative tools (e.g., clear-excel-range), so it falls slightly short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true. The description adds tips on update fields but doesn't detail side effects or response. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, front-loading the purpose and followed by a useful tip section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers prerequisites and common use cases, providing sufficient context for a tool with 6 parameters and 3 required ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%. The description adds meaning by listing specific updatable properties (status, title, dueDateTime) and explaining the confirm parameter, going beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a todoTask object, with specific verb and resource. It distinguishes from sibling tools like create-todo-task and delete-todo-task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios (mark complete, reopen, rename, etc.) and prerequisites (todoTaskListId, todoTaskId). It does not explicitly mention when not to use, but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context like no email sent and inheritance, but annotations have destructiveHint=true while the operation is not destructive (it creates or returns existing link). This contradiction reduces transparency. No explanation of destructive consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient, with a tip and clear structure. It includes key information without unnecessary words, but could be slightly more concise in the tip section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description informs about return (permission with link.webUrl) and mentions inheritance. Covers main use case, but lacks details on error conditions and full response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, and description adds value by providing enums for type and scope, and clarifying the effect of body fields (e.g., no email). However, it omits some schema fields like message and recipients, so not fully complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool creates a sharing link for a driveItem, distinguishes between creating a new link and returning an existing one, and differentiates from the sibling tool 'share-drive-item' by noting it does not send invitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: 'Pair with share-drive-item when you want to grant explicit access; use this when you only need a URL to paste into a doc/email/chat without triggering OneDrive notifications.' Also explains behavior when link already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description aligns by noting sharing/delegation. It adds context about the returned permission's id being used by update and delete tools. However, it does not discuss potential side effects like overwriting existing permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a brief paragraph and a tip. It front-loads the purpose and includes essential examples without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested object complexity and lack of output schema, the description adequately explains the action, provides an example, and mentions the return value. It covers the key aspects needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is high at 75%, and the description supplements with a concrete body example showing the structure and role options. This adds meaning beyond the schema, especially for the emailAddress and role fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a calendarPermission to share or delegate a calendar. It specifies the verb 'create' and the resource 'calendarPermission', distinguishing it from sibling tools like list-, update-, and delete-my-calendar-permission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a tip about sharing the user's primary calendar and suggests using list-users to resolve the recipient SMTP. It gives clear context for when to use the tool, but does not explicitly exclude conditions or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, readOnlyHint=false), the description discloses a critical behavior: the body must be a full HTML document; otherwise, it fails silently or creates malformed pages. This is valuable context that helps the agent avoid errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single sentence for the main purpose, followed by a clarification for section targeting, and a highlighted tip for the body format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers how to create pages and the required body format, but it does not mention what the response contains (e.g., the created page object), which is important for an agent to process the result. Given no output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters, with descriptions for 3 (confirm, includeHeaders, excludeResponse) but no description for the 'body' parameter. The description compensates by specifying that the body must be a full HTML document, adding essential semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new OneNote page in the default notebook's default section, specifies the endpoint, and distinguishes from sibling tools by noting that this tool is only for the default notebook (with a workaround for other sections via query parameter).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (default notebook) and how to target a different section using the sectionName query parameter. It mentions that for other notebooks, you should create pages in a specified section, but does not name a specific sibling tool as the alternative, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the write nature is known. The description adds behavioral details: creates a draft (not sending), constraints on parameters, MIME encoding requirements, and tips about HTML and signatures. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate paragraphs for JSON and MIME formats, plus a tip section. Every sentence adds value, though it is slightly verbose. The key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers core usage and constraints, it lacks information about required permissions, the response format (no output schema), and error handling. It mentions updating the draft later but doesn't specify the return type or confirmation feedback.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: explains the body parameter's two formats with constraints, and provides clear guidance for messageId (pass under 'messageId', not 'id'). Schema coverage is 80%, but the description fills gaps like MIME format instructions and the comment vs body restriction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a draft to reply to the sender, specifying JSON or MIME format. This distinguishes it from sibling tools like create-forward-draft and create-reply-all-draft. The verb 'create' and resource 'draft to reply to sender' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use JSON vs MIME format and highlights constraints (e.g., cannot specify both comment and body). It mentions an alternative: replying in a single operation with reply-mail-message. However, it does not explicitly compare with create-forward-draft or create-reply-all-draft.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's mention of 'Create' aligns. The description adds value by specifying the return structure and the limitation on built-in lists. It could further clarify authorization requirements or rate limits, but given annotation coverage, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core action in the first sentence and additional details in a single tip block. It avoids unnecessary fluff and is front-loaded. However, it could be slightly more streamlined by merging the tip into the main description, but it remains clear and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately lists the returned fields (id, displayName, isOwner, isShared, wellknownListName) and addresses the built-in lists edge case. It pairs well with sibling tools. Minor gaps: no mention of error scenarios or permissions, but for a creation tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description compensates by detailing the required 'body' parameter format ('{ displayName: 'My new list' }') and explaining the 'wellknownListName' property. Standard parameters (confirm, includeHeaders, excludeResponse) are not elaborated, but they are self-explanatory. Overall, the description adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create'), the resource ('lists object' / Microsoft To Do task list), and the specific context (To Do app sidebar). It distinguishes from sibling 'create-todo-task' by mentioning pairing. The verb and resource are explicit, and the sibling differentiation is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance: the required body format, expected return fields, and a tip to pair with create-todo-task. It also warns about built-in lists that cannot be re-created. However, it doesn't explicitly contrast with alternative tools (e.g., update-todo-task-list) or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description clarifies that 'the event remains in the calendar as declined unless the user deletes it,' adding important context beyond annotations. It also explains the proposedNewTime behavior and optional body fields, providing good insight into side effects and user experience.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a tip) and front-loaded with the main purpose. Every sentence adds value: the core action, the proposed time alternative, and the tip with optional fields. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately covers the tool's behavior (event remains as declined), optional parameters, and the proposed new time feature. It could mention the return format (e.g., success/failure) but is otherwise complete for a typical decline action among many sibling calendar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema: it explains the eventId usage ('Pass it under the name eventId... use the id field'), clarifies the confirm parameter's role for destructive operations, and describes the optional body fields (Comment, SendResponse, ProposedNewTime). Schema coverage is high (80%), but the description enriches understanding of critical parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Decline invitation to the specified event in a user calendar.' The verb 'decline' and resource 'calendar event' are specific. It also mentions the optional proposed new time, distinguishing it from other event response tools like accept, tentatively accept, or cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the proposedNewTime parameter and provides a tip about the optional body (sendResponse, comment). However, it does not explicitly contrast with sibling tools (e.g., when to decline vs. cancel) or provide exclusion criteria for when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description adds contextual detail about the long-term effect on message classification. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a tip, front-loaded with the action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-by-ID tool with full schema and no output schema, the description covers the purpose, prerequisite, and post-deletion behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. The description adds only implicit reference to the ID, not enhancing parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'Focused Inbox override', specifying the effect that future messages revert to default behavior. It distinguishes from sibling tools like list, create, and update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear prerequisite: 'Use list-focused-inbox-overrides to find the ID first.' Does not explicitly state when not to use or list alternatives, but the nature of a delete tool makes usage straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show destructiveHint=true. The description adds that built-in lists cannot be deleted and the API returns an error for those. This extra context about what is and isn't allowed goes beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a brief tip. Front-loaded with the main action. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool, it covers the action, limitations (built-in lists), prerequisite (get IDs), and implicitly the need for confirmation via the confirm parameter (though in schema). No output schema needed; success/error is standard. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no parameter-specific details beyond the schema. The tip about getting list IDs is helpful but not about parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Deletes a todoTaskList object' and specifies it's for Microsoft To Do task lists. It distinguishes from siblings by noting that built-in lists cannot be deleted and directs users to list-todo-task-lists for IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use to delete user-created lists, not built-in ones (which causes an error). It also advises getting list IDs via list-todo-task-lists. It could explicitly state when not to use (e.g., for built-in lists) but the limitation is already clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clarifies which properties are set (horizontalAlignment, verticalAlignment, wrapText, columnWidth, rowHeight) and which are excluded (font, fill, borders), adding context beyond the annotations. However, it does not disclose whether unspecified formatting properties are preserved or overwritten, nor does it mention any confirm-gate requirements, despite the destructiveHint annotation. This leaves a partial but noticeable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core purpose, and each sentence earns its place: the purpose, the required parameter, the body fields, and the exclusion/alternatives. The emoji tip makes it visually scannable without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main use case and exclusions, it fails to mention the other four required path parameters (driveId, driveItemId, workbookWorksheetId, body) and does not explain what happens to unspecified formatting properties. Since there is no output schema and annotations only provide generic safety hints, the description leaves the agent with some ambiguity in fully invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 88% description coverage and includes many body properties, but the description adds key semantics by narrowing the effective body to {horizontalAlignment, verticalAlignment, wrapText, columnWidth, rowHeight} and explicitly saying font/fill/borders are not set here. This prevents misuse of the schema's broader body shape. It also gives address examples, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Format an Excel range,' a specific verb+resource statement. It goes on to say 'Apply rangeFormat properties to a specific range' and explicitly distinguishes this tool from format-excel-range-font, format-excel-range-fill, and format-excel-range-border by stating that font, fill, and borders are NOT set here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct usage guidance: it identifies the required path parameter 'address' with examples, lists the specific body fields to use, and explicitly names alternative tools for font, fill, and border formatting. This tells the agent exactly when to use this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety profile is clear. The description adds behavioral details such as supported OData parameters ($filter, $top, $orderby) and pagination, but does not cover all edge cases or error conditions. Still, it provides good transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise at four sentences, with a clear structure: core purpose, TIP about usage, and supported features. It is front-loaded but could be slightly tighter by removing redundant phrases like 'under the specified contact folder' (implied by tool name). Still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema), the description covers the main purpose, differentiation from siblings, and key supported features. It could be improved by briefly noting that the response is a list of folder objects or mentioning pagination via @odata.nextLink, but overall it is adequate for an AI agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 12 parameters described in the input schema. The description does not add significant meaning beyond the schema, referencing OData parameters generally but not explaining each parameter in detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves child folders under a specified contact folder, specifying returned fields (id, displayName, parentFolderId). It differentiates from sibling tools like list-contact-folders by explaining that this tool goes one level deeper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The TIP explicitly instructs when to use list-contact-folders for top-level folders and this tool for deeper traversal. It notes that contact folders are typically flat in Outlook but Graph allows nesting, providing practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only safe operation. Description adds return structure (timeZoneInformation with alias and displayName), case-sensitivity tip, and pagination context, providing useful behavioral details beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with main purpose paragraph and a helpful tip section. Slightly verbose but front-loaded and clear. Could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers output structure (alias, displayName), format options, and integration with update-mailbox-settings. Without output schema, description explains return fields adequately. Standard Graph params are documented in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaningful detail for TimeZoneStandard (explains enum values and case-sensitivity) and reinforces pagination parameters. Adds moderate value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets the list of supported time zones for the user's mailbox server, specifies format options (Windows vs IANA), and distinguishes from related tools like update-mailbox-settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use (e.g., before changing mailbox time zone), which format to choose, and mentions related tool. Does not explicitly state when not to use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only (readOnlyHint: true). The description adds context by specifying input URL formats and the output type (standard joinWebUrl), which goes beyond the annotation, though it does not detail error behavior or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with no redundant words. It is front-loaded with the primary action and efficiently conveys the usage recommendation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, and clear annotations), the description provides all necessary context: what it does, which URL formats it handles, and when to use it. No additional information is required for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'url' has a schema description 'Teams meeting URL in any format' that already captures the essence. The tool description adds no extra semantic information beyond the schema, and with 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Converts any Teams meeting URL format into a standard joinWebUrl.' It specifies the verb 'converts' and the resource 'Teams meeting URL', and explicitly lists the supported formats, making it distinct from sibling tools that perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this before list-online-meetings when the user provides a recap or short URL.' This tells the agent when to invoke the tool, though it does not explicitly state when not to use it or mention alternatives beyond that specific context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds value by explaining that the message is saved in the Sent Items folder, the error condition when body and comment are both specified, and the RFC 2822 replyTo behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and a tip, front-loading the main purpose. It is slightly verbose due to repeated format details, but each sentence adds value. The tip provides additional useful context without cluttering.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, JSON/MIME choice, no output schema), the description covers key behaviors: format options, constraints, saving to Sent Items, and the draft alternative. It does not detail the response format but mentions the sent folder, which is sufficient for a send operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema description coverage is 80%, the description adds crucial semantics beyond the schema: the exclusivity constraint between comment and body in the message parameter, which is not captured in the schema. It also clarifies the JSON vs MIME usage for the body parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replies to all recipients of a message, distinguishing it from siblings like reply-mail-message (reply to sender) and create-reply-all-draft (draft version). It explicitly mentions the draft alternative and differentiates between JSON and MIME formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (to reply-all) and mentions the alternative of creating a draft. However, it does not explicitly exclude using it when just replying to the sender, relying on the tool name. It provides good guidance on JSON vs MIME format choices and constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true and readOnlyHint: false, so the description adds value by noting that the message is saved in the Sent Items folder and by describing the 400 error case. This goes beyond annotations without contradictions, earning a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise given the complexity, with clear bullet points and a front-loaded purpose. It could be slightly shorter, but it effectively organizes information without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, two formats), the description covers key aspects: format choice, parameter constraints, and the sent items folder. The lack of output schema details is acceptable as the description focuses on inputs. The tip addresses a common use case. Score 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 80% schema description coverage, the baseline is 3. The description adds meaning by explaining the JSON vs MIME choice, the constraint on specifying both comment and body, and the tip about using the comment field. This extra context raises the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replies to the sender of a message, distinguishes between JSON and MIME formats, and includes a tip emphasizing preserving HTML formatting and using the comment field. This specificity and sibling differentiation (e.g., reply-all) justify a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use JSON vs MIME, constraints on parameters (comment vs body), and the behavior regarding reply-to recipients. However, it does not explicitly contrast with sibling tools like reply-all-mail-message or forward-mail-message, leaving some ambiguity. Still, the guidance is detailed and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true and readOnlyHint=false. The description adds the concurrency requirement (If-Match/ETag), which is behavioral context beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences clearly stating the purpose and a critical tip. No wasted words, and the essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the complex nested input schema and lack of output schema, the description does not explain the body structure, response, or other parameters like plannerBucketId or confirm. It covers the key prerequisite but is incomplete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), so the schema already documents most parameters. The description adds value by clarifying the If-Match parameter's source and usage (from get-planner-bucket with includeHeaders=true), which enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'plannerbucket object', distinguishing it from sibling tools like create, get, or delete. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a critical usage guideline: the requirement for an If-Match header with an ETag from get-planner-bucket. It implies when to use this tool (after fetching the bucket) but does not explicitly state when not to use it or offer alternatives, which prevents a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behavioral traits beyond annotations: size limit, JPEG format, base64 encoding, PATCH/PUT support, automatic HD variant generation, and required permissions. No contradiction with annotations (destructiveHint: true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with about 5 sentences plus a tip. It is front-loaded with purpose. The tip provides useful extra context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description covers purpose, input constraints, permissions, and side effects (HD variants). It could mention response format, but it's not essential given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the JPEG constraint and HD variant info, but the body parameter's encoding is already documented in the schema. For confirm, it adds gate behavior. Overall marginal addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and resource 'photo' for specified entities (contact, group, team, user). It provides specific format and size constraints, and distinguishes itself from a retrieval sibling via the tip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context including permissions, format, and size limits. It mentions an alternative for retrieval (download-bytes) but does not explicitly compare with other upload tools. The usage is implied rather than stated with explicit when-to-use guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds crucial detail beyond that by explaining the exact effects of each applyTo mode: 'Contents' wipes values but keeps formatting, 'Formats' resets styling but keeps values, and 'All' wipes both. This tells the agent precisely what gets destroyed, going beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear one-line summary followed by a tip that explains the key parameter and use case. Every sentence adds value, with no wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations and schema, the description is largely complete. It covers the tool's purpose, usage context, and the nuanced behavior of the main parameter. The absence of an output schema means return values need not be documented. Minor gaps remain (e.g., no mention of the confirm parameter), but those are covered in schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has descriptions for most parameters, but the body.applyTo parameter is not described in the schema. The description adds significant meaning by explaining the three allowed values and their behavioral implications. This fills a critical gap, even though schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Clear an Excel range.' It elaborates on clearing contents and/or formatting, and distinguishes itself from sibling tools like delete-excel-range and update-excel-range by emphasizing resetting a section before a fresh write rather than overwriting cell-by-cell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific guidance: 'Use this to reset a worksheet section before a fresh write rather than overwriting cell-by-cell.' This clearly indicates when to use the tool, though it doesn't explicitly name alternatives. The context is sufficient for an agent to choose this over similar Excel range tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, lowering the bar. The description adds significant behavioral context beyond annotations: the operation is asynchronous, returns 202 Accepted, and provides a Location header pointing to a monitor URL. This discloses the expected response pattern and async nature without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose ('Copy a drive item') followed by a labeled TIP that adds async semantics, body format, response behavior, and use cases in four compact sentences. Every sentence contributes meaningful information, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description appropriately covers the return behavior (202 Accepted + Location header for async monitoring). It also addresses the complex nested body schema with an example. It could optionally explain how to consume the monitor URL or handle job completion, but for an async copy operation the essential context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), providing a baseline of 3. The description adds a concrete body example ('{ parentReference: { driveId: '...', id: '...' }, name?: 'New Name.xlsx' }') that demonstrates how to structure the complex nested body parameter, which goes beyond the schema's property list by showing a realistic usage pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Copy a drive item') and elaborates with 'Asynchronously copy a file or folder to a new location and/or name.' It clearly distinguishes from the sibling move-rename-onedrive-item by framing the operation as creating a copy, and the template-cloning use cases reinforce the copy semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with 'Ideal for duplicating templates... bulk file provisioning, or preserving an immutable snapshot of a working file,' giving concrete usage scenarios. It does not explicitly name alternatives or exclusions relative to move-rename-onedrive-item, but the use cases strongly imply when copying is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true (write operation). The description adds that it creates a contact inside a specific folder. No additional behavioral details are needed 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with key information. Two sentences plus a tip and example, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description covers the input well. It lacks explicit explanation of the return value, but that is common. The tips and examples provide sufficient context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, matching the baseline of 3. The description adds an example of the contact payload, but most parameter details are already in the schema. The tip about contactFolderId is helpful but not enhancing semantics significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a contact to a specified folder (root or other), distinguishing it from create-outlook-contact which writes to the default folder. The verb 'Add' and resource 'contact' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use this tool when organizing contacts into named folders, and use create-outlook-contact for the default folder. It also gives a tip on how to obtain the folder ID via list-contact-folders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds meaningful context by noting that only non-inherited permissions can be deleted and that you should list permissions first. It does not go into full detail about failure modes or response behavior, but with annotation coverage, this is sufficient additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: a clear action statement followed by a helpful tip. It is front-loaded and every sentence carries relevant information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation with no output schema, the description covers the essential prerequisite, the inherited-permission limitation, and the action itself. It could mention what response the user gets or add detail about consequences, but given the moderate complexity and good annotations, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all seven parameters, so the description does not need to compensate. The only slight addition is the tip to find the permission ID, which aligns with the permissionId parameter but does not add new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('drive item permission'), and adds clarifying detail about removing a specific permission from a file or folder. It also distinguishes behavior from sibling tools like list-drive-item-permissions and create-drive-item-share-link by focusing on deletion of an existing permission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool explicitly advises using list-drive-item-permissions first to obtain the permission ID, which is a clear prerequisite and sequential guideline. It also states a key constraint: only permissions that are not inherited can be deleted, implicitly telling the user when this tool is NOT appropriate (i.e., inherited permissions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations by explaining that deleting a range shifts remaining content and by giving the shift direction options. Annotations already mark this as destructive, and the description aligns with that. It doesn't mention confirmation or side effects, but the destructive hint covers the core safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the purpose stated first, followed by a concise tip. Every sentence earns its place, and the bullet-point style for the tip improves readability without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema, the description adequately explains the action and key parameter semantics. It doesn't describe return values or prerequisites, but those are less critical for a delete tool, and the schema covers the confirmation parameter. The description is sufficient to guide correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema provides descriptions for most parameters (88% coverage), the description adds critical meaning for the 'body' parameter by specifying the valid values for 'shift' ('Up' or 'Left') and clarifying their effect. This goes beyond the schema's bare string type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Delete an Excel range.' It distinguishes from siblings like clear-excel-range by specifying that remaining content is shifted, and provides the shift options ('Up' or 'Left'). This clearly communicates the tool's unique behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage guidance via the tip, explaining how to delete cells and shift content, and specifically advises using 'Up' to delete entire rows. While it doesn't explicitly contrast with alternatives or say when not to use it, the context strongly implies the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is clear. The description adds valuable behavioral context: that it revokes share or delegate access, and that permissions with isRemovable=false cannot be deleted and will produce an error. This goes beyond the basic annotation signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and the tip adds critical information in a compact way. No wordiness or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple delete operation with no output schema, the description covers the main purpose, key limitation (non-removable permissions), and how to obtain the ID. The confirm and If-Match parameters are documented in the schema. The only missing context is the success response shape, but that is not critical for a delete tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra value by telling the agent to get the calendarPermissionId from list-my-calendar-permissions, which is not in the schema. This helps the agent source the correct parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'my calendar permission', and the tip further clarifies it revokes a calendar share or delegate access. This clearly distinguishes it from sibling tools like list-my-calendar-permissions, create-my-calendar-permission, and update-my-calendar-permission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to get the permission id via list-my-calendar-permissions, which is a clear prerequisite. It also warns about non-removable permissions (isRemovable=false) that will cause Graph to return an error, giving the agent guidance on when the tool will fail. No explicit mention of alternatives, but the context makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show destructiveHint=true. The description adds that no further change notifications will be sent, clarifying the effect. No contradictions, and the description complements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs, front-loading the purpose. Each sentence adds value, and the tip section is helpful without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, 5 parameters fully covered by schema, and presence of annotations, the description adequately explains the effect and prerequisite. No output schema needed, and the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining how to get subscriptionId from the subscription object's id field, which aids correct usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a subscription' and specifies it's for webhook subscriptions. It differentiates from sibling tools like list-subscriptions, create-subscription, etc., by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using this tool to clean up stale subscriptions or stop notifications, and directs to list-subscriptions to find the id. It provides clear use context but lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and non-read-only, and the description adds valuable behavioral nuance: it modifies only one border side per call, requiring multiple calls for a complete outline. This behavior is not derivable from the schema or annotations alone. It does not warn about overwriting existing border formatting, but the destructive hint covers the risk profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and the tip is dense and immediately actionable. It wastes no words and does not repeat schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with moderate complexity (9 params, 6 required, nested body) and no output schema, the description plus the rich parameter schema covers the essential usage pattern. It tells the agent how to select a side and how to achieve a full border outline. It does not discuss return values or confirm-gate behavior, but those are either not defined or already described in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers most parameters (89%) including body color/style/weight enums and path segment descriptions. The description adds essential semantics by enumerating the sideIndex values (EdgeTop through DiagonalUp), which the schema leaves as a generic 'Value for the sideIndex path segment.' This lifts it above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Format an Excel range border,' a specific verb+resource that immediately identifies the tool's purpose. The tip further clarifies that it sets one border side at a time, distinguishing it from sibling formatting tools like format-excel-range-fill and format-excel-range-font.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Sets one border side' and explains how sideIndex selects among the eight possible sides. It gives a clear directive for the common full-outline use case: 'To outline all four edges, call once per side.' It lacks explicit comparison to alternate tools, but the usage context is well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it details the forwarding mechanics (organizer notification and attendee list update for Microsoft 365, lack of convenience for Outlook.com). This aids the agent in understanding side effects. Could mention permissions or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, around 4 sentences, front-loading the core purpose. The tip is helpful and compact. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, nested objects, no output schema), the description adequately covers the use case, main behavior, and parameter tips. It could mention the return value or potential errors for full completeness, but it is already informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a structural hint for the 'body' parameter (ToRecipients and Comment) and clarifies that eventId should be passed as 'eventId' not 'id'. Schema coverage is high (80%), and the description adds meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'forward' and the resource 'calendar event', distinguishing it from siblings like accept, decline, or create. It also covers both organizer and attendee scenarios and notes the Outlook.com limitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to forward (for both organizer and attendee) and notes behavior differences. However, it does not explicitly state when not to use it or mention alternatives, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond annotations: it returns specific fields (address, values, formulas, numberFormat, rowCount, columnCount) and clarifies the semantics of 'used range' as encompassing cells with values or formatting. Also mentions optional $select trimming, which is not in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear verb-first sentence followed by a practical tip and return field list. Every sentence earns its place, and the format is scannable. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description compensates by listing return fields. It also explains the use case and optional $select. While it doesn't address all parameters (fetchAllPages, includeHeaders, excludeResponse), those are fully covered in the schema. Overall, the description plus schema provides sufficient context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the listed parameters, so the baseline is 3. The description adds extra meaning by noting 'Optional $select to trim the response,' which is not present in the input schema. This provides useful parameter-level guidance beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get an Excel used range.' It further defines what a used range means (smallest range encompassing cells with values or formatting) and lists the returned data fields. This distinguishes it from sibling tools like get-excel-range, which fetches a specific range, rather than discovering bounds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover the populated bounds of a sheet before reading or appending — avoids guessing how far data extends.' This gives a clear use case and implies when to choose this tool over others. It doesn't explicitly state when not to use it, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and non-destructive. Description adds context about navigation properties requiring separate GET methods, and notes beta status. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first explains purpose, second provides actionable tip and distinction. No fluff, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains the rich profile structure and navigation properties. Annotations include openWorldHint. Slightly inconsistent about 'given user' vs 'signed-in user', but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters with detailed descriptions. Description adds value by explaining $expand usage with an example, enhancing the semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves the rich profile object, contrasting with get-current-user. Specific verb 'retrieve' and resource 'profile object'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool for richer profile data (skills, projects) versus get-current-user, and suggests using $expand. Lacks explicit when-not-to-use, but provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the response includes @odata.etag and that includeHeaders can be used to get it. This adds value beyond the annotations (readOnlyHint=true, destructiveHint=false) by specifying a key behavioral trait for downstream usage. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—two sentences plus a tip. Every sentence adds value: the first states purpose, the second provides crucial usage context. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description does not detail return fields, but it does note the ETag, which is important. The tip about includeHeaders adds completeness for the common use case. Slight gap for a full picture, but sufficient for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all parameters. The description adds minimal value beyond the tip about includeHeaders, which is a usage hint rather than parameter semantics. Baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve the properties and relationships' with the specific resource 'plannerTaskDetails object'. It uses a specific verb and resource, distinguishing it clearly from sibling tools like 'get-planner-task' and 'update-planner-task-details'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a tip that explicitly mentions using includeHeaders=true to get the ETag required for 'update-planner-task-details'. This provides clear context for when this tool is useful (before an update). However, it does not explicitly state when not to use it or mention alternatives, but the guidance is still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as destructive (destructiveHint: true) and not read-only (readOnlyHint: false). The description adds valuable context beyond annotations by specifying that existing content is shifted, which clarifies what the destructive behavior entails. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action ('Insert an Excel range'). The tip adds necessary usage detail in just two sentences, with no waste. The emoji and tip formatting make the key guidance stand out without increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should cover the core behavior and key parameters, which it does. It explains the essential 'shift' parameter and the overall effect. It does not mention return values or the required path parameters, but those are well-documented in the schema, and the absence of an output schema lowers the expectation for return-value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (88%), so the bar is lowered. However, the body parameter, especially the 'shift' property, lacks a description in the schema. The description compensates by explaining the allowed values ('Down' or 'Right') and their meaning, which is essential for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Insert') and resource ('Excel range'), then clarifies the exact behavior ('Insert blank cells at the given range, shifting existing content'). This distinguishes it from sibling tools like update-excel-range, delete-excel-range, and clear-excel-range, which have different verbs and behaviors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool by explaining the shift parameter ('Body: { shift: 'Down' } or { shift: 'Right' }') and its practical effect ('Use 'Down' to insert blank rows above existing data'). It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: returns only HTML format, does not expand recurring events, can get events from another user's calendar. No contradiction with readOnlyHint or destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with repetition (e.g., 'single instance meetings and series masters' vs 'only returns seriesMaster'). Could be more concise, though front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and no output schema, the description covers the core behavior and limitation well, but could benefit from mentioning return structure or pagination hints already present in parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add extra parameter meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists event objects in the user's mailbox, distinguishing from expanded instances by mentioning calendar view and event instances. The tip explicitly warns about recurrence handling and suggests an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (listing events) and when not to (need expanded instances), with specific alternatives like get-calendar-view and get event instances. The warning is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context: it warns about large payloads with fetchAllPages, explains that $search cannot combine with $filter, and recommends $select to limit fields. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections: main purpose, critical formatting for $search, and usage recommendations. Every sentence is informative, though some repetition could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains pagination via @odata.nextLink, filtering limitations, and return size reduction tips. It covers all essential aspects a developer needs to list messages effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description enriches parameters like $search with concrete double-quote wrapping and KQL examples, and gives advanced usage tips for $top, $count, and fetchAllPages. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves messages from a user's mailbox or a specific folder. It distinguishes from siblings like list-mail-messages (which lists all messages without folder scope) and list-mail-folder-messages-delta, making the purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use $search, $select, fetchAllPages, and pagination. It includes critical syntax for KQL search. However, it does not explicitly state when not to use this tool compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false; description adds the transverse nature, default ordering, and OData support. No contradictions. Adds useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief yet packed with valuable information. Front-loaded with purpose, then tips, examples, and comparisons. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema), the description covers purpose, default behavior, OData capabilities, and pagination. It does not detail the response structure, but that is somewhat mitigated by the 'list of page objects' notion and the mention of @odata.nextLink. Adequately complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds practical usage tips (e.g., start small $top, use $select to reduce fields, pagination via @odata.nextLink) and clearly explains OData parameters $filter and $expand, which enhances the semantic understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of page objects across all notebooks/sections. It uses a specific verb+resource and distinguishes from siblings by positioning itself as a transverse alternative to walking the notebook hierarchy, naming sibling tools list-onenote-notebooks, list-all-onenote-sections, and list-onenote-section-pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Use this instead of bouncing through... when you have a topic in mind.' Provides tips on default ordering and supported OData queries. Does not explicitly list exclusions but gives sufficient context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details: $select is not supported and causes 400 error, provides filter examples with status values, and suggests $top for limiting results. It does not contradict annotations and adds practical constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no unnecessary words. It front-loads the formal purpose, then uses a clear bullet-style tip section. Every sentence adds value: purpose, prerequisite, warning, filter guidance, limit suggestion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema, the description covers essential usage: prerequisite tool, main parameters, common filters, and limitation. Pagination details are left to parameter descriptions. The description is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema by highlighting key parameters (todoTaskListId as required, warning about $select, filter status examples, $top usage). It does not repeat all schema descriptions but adds actionable tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves todoTask resources from a specified todoTaskList, using specific verb and resource. It distinguishes from siblings like get-todo-task (single) and create/update/delete. The tip explicitly names the prerequisite tool list-todo-task-lists, reinforcing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use (to list tasks in a To Do list) and provides clear instructions: require todoTaskListId, get it from list-todo-task-lists, avoid $select, use $filter and $top. It does not explicitly state when not to use, but the naming and context imply it's for bulk listing rather than single retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint: true). The description adds behavioral detail about the merge operation—specifically that body.across determines whether the entire range merges into one cell or each row merges separately. It doesn't warn about potential data loss when merging non-empty cells, but this is partially covered by the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a clearly structured tip. It front-loads the action and explains behavior without unnecessary length or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a rich schema, the description is sufficiently complete: it covers the core merging behavior, the two modes, and a use case. It lacks details on return values and prerequisites, but these are not critical given the schema and absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (88%), but the description adds essential meaning to the body.across parameter by explaining that false merges the whole range into one cell and true merges each row separately. This goes beyond the bare type/default in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Merge an Excel range' and specifies that it merges cells into a single cell (or row-wise with across: true). This distinguishes it from sibling tools like unmerge-excel-range and other Excel formatting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides use cases ('building styled headers, banner rows, and report layouts') and explains the two merge modes (across: false vs true), which implies when each setting is appropriate. However, it does not explicitly contrast this tool with alternatives like unmerge-excel-range or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the reminder will re-fire at the new time, providing behavioral context beyond the destructiveHint annotation. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences plus a tip, no wasted words. Front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers the key parameter structure and behavior. No output schema, but the action is simple enough. Could mention eventId but schema covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value for the body parameter (NewReminderTime) with format details, but does not cover other parameters like eventId or confirm. Schema provides descriptions for those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'postpone' and the resource 'reminder for an event in a user calendar'. It distinguishes from sibling tools like dismiss-calendar-event-reminder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip indicates it's for triggered event reminders but does not explicitly state when not to use or compare with dismissing. However, the context of siblings implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond annotations: it states that the default 'Contacts' folder may not be renameable, which is a notable constraint. Annotations already indicate destructiveHint=true, so the description complements this with a specific limitation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a short sentence stating the purpose, followed by a compact tip with key details. Every sentence earns its place, and the structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (2 required) and nested body structure, the description covers the essential aspects: the purpose, the main writable fields, and a constraint. It lacks details about the confirm gate or response options, but those are common and inferred from schema. The absence of output schema is acceptable as description does not need to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 80% schema coverage, the description adds value by explicitly stating that displayName and parentFolderId are the writable fields in the body, clarifying what the agent should set. It does not mention the other parameters (confirm, includeHeaders, etc.), but those are standard across tools and do not require additional explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'Update' and the resource 'contactfolder object', distinguishing it from siblings like create-contact-folder and delete-contact-folder. It specifies that it updates properties of an existing contact folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it updates a contact folder, highlights the two writable fields (displayName and parentFolderId), and notes that the default folder may not be renameable. It also suggests getting the folder id via list-contact-folders. However, it does not explicitly contrast with create or delete tools, but the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint: true) and note the confirm gate. The description adds valuable context: the body shape, the 'no formal table required' caveat, and the requirement that inner-array values match column count. It doesn't discuss overwrite behavior or permissions, but given annotation coverage, the added context is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but packed with practical details. It starts with a clear purpose statement, then a helpful tip, body format examples, use cases, and a constraint. Each sentence earns its place, though the body-format inline code could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description covers the purpose, usage patterns, and critical body syntax. It does not describe the return value or error cases beyond the confirm gate, but the core functionality is well-documented and the description differentiates it from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 88% but the 'body' parameter is a generic object with additionalProperties true, providing no structure. The description compensates with explicit body format examples: { values: [['v1','v2','v3']] } for single row and [['a','b'],['c','d']] for multi-row, plus the column-count rule. This is essential information that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an Excel range' and elaborates that it sets values, formulas, or number format, distinguishing it from insert/delete/clear operations. It explicitly notes it works on any range, not just formal Excel tables, which differentiates it from table-specific tools like update-excel-table-row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases: append (target next empty row), update (single cell), and prepend-style edits. It explains the body format and column-count constraint. However, it doesn't explicitly mention when to use alternative tools like insert-excel-range or format-excel-range, though the usage examples imply the intended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true. The description reinforces mutation with 'Change writable properties' and 'save the changes'. Adds value by hinting at partial update semantics and providing a common usage scenario. Does not disclose return value details, but the absence of an output schema reduces the need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a tip, all front-loaded and no fluff. Every sentence serves a purpose: stating action, giving practical advice, and illustrating a typical use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nested schema (conditions, actions), the description provides a high-level overview and a concrete example. It does not cover error handling or retrieval of folder IDs, but the schema and sibling tools fill in. Adequate for an experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, so the schema already documents most parameters. The description adds useful context: 'Send only the properties to change' and provides an example (isEnabled: false). This goes beyond the schema's factual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Change writable properties on a messageRule object and save the changes.' This is a specific verb+resource combination. Distinguishes from sibling CRUD tools (create-mail-rule, delete-mail-rule) and provides a common use case (disabling a rule).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip advises using the Inbox folder ID and to send only changed properties. It implies an existing rule is needed, but does not explicitly exclude using this for creating new rules. Context from sibling tools helps, but the description alone could be more explicit about when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds behavioral details: the range address determines the worksheet, errors on invalid address or overlap. It does not explicitly state it modifies the workbook, but creation implies modification. The addition of error conditions adds transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short paragraphs plus a tip. The first sentence immediately states the main action. The tip is clearly formatted and adds crucial prerequisite information. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, errors, and prerequisite relationship. However, it lacks information about the return value (e.g., the created table object or success status). Since there is no output schema, the description should explain what the tool returns. This is a notable gap given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (86%), but the description adds value by explaining the address and hasHeaders parameters through an example and noting that the address determines the worksheet. This goes beyond what the schema provides. For parameters already well-documented in schema, the description still offers practical context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new table, defines the role of the address parameter, and distinguishes itself from related sibling tools like add-excel-table-rows by noting it is a prerequisite. The tip provides a concrete example, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: required before add-excel-table-rows, update-excel-table-row, or delete-excel-table-row on a plain-cells sheet. It also mentions error conditions (invalid address, overlapping table) which guide when not to use. This provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations destructiveHint=true indicate mutation. The description explains the creation of an upload session, return of an upload URL, and resumption capability. It doesn't mention session expiry or other limitations, but adds useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear and well-organized, with a tip at the end. It could be slightly more concise, but it effectively communicates required information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (upload URL). It covers file size guidance, steps, and an example. Missing details about optional parameters (confirm, includeHeaders) and session lifetime, but overall adequate for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (high). The description adds a concrete example for the 'body' parameter (AttachmentItem structure), which is valuable for a complex nested object. Other parameters (confirm, includeHeaders) are not discussed, but the schema provides their descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an upload session for attaching large files (3-150MB) to Outlook items, and distinguishes from the alternative POST method for smaller files. It specifies the resource (Outlook item: message or event) and the action (iteratively upload ranges).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool (file size between 3MB and 150MB) and when not to (use POST for <3MB), with references to documentation. The tip with an example body structure aids understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations (which indicate destructiveHint=true) by detailing the draft creation process, the handling of replyTo and toRecipients per RFC 2822, the constraint that specifying both comment and Message.body returns 400, and that signatures are not added via Graph. It fully discloses the tool's behavior and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for JSON format and a tip. It front-loads the purpose. While slightly verbose, each sentence adds value (e.g., the tip about HTML replies and signatures). Could be trimmed slightly, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive, multiple formats, nested params) and no output schema, the description covers creation, format options, constraints, and limitations. It does not describe the return value (likely the draft message), but the tool's purpose is clear. It is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 80% schema description coverage, the description adds meaningful context for key parameters: the body parameter's comment vs Message distinction, the confirm parameter for destructive gates, and the messageId parameter (use the id field). The tip clarifies the relationship between body.content and body.contentType. It does not explain all nested properties, but the schema covers most.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a draft to reply to the sender and all recipients. It distinguishes from similar sibling tools like 'create-reply-draft' (reply to sender only) and 'create-forward-draft' (forward). It specifies JSON and MIME formats, making the purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed guidance on when to use JSON vs MIME, constraints (e.g., comment and body cannot both be specified), and mentions an alternative action ('reply-all to a message in a single action'). It also includes a tip on HTML replies and notes that signatures are added by the Outlook client. However, it does not explicitly list when not to use this tool (e.g., when only replying to sender, use create-reply-draft).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description adds valuable context: the default folder cannot be deleted, the folder moves to Deleted Items rather than being permanently removed, and that the id must be obtained via list-contact-folders. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a tip, each sentence adds unique value. It is front-loaded with the core purpose and immediately provides actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description covers key aspects: what it deletes, what cannot be deleted, where items go, and how to get the required id. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal parameter-specific info beyond the schema, only indirectly explaining contactFolderId by referencing list-contact-folders. The schema descriptions are already clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a contact folder, specifies that the default 'Contacts' folder cannot be deleted, and distinguishes from sibling tools like update-contact-folder and create-contact-folder by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a tip to use list-contact-folders to get the folder id, warns about the default folder not being deletable, and explains that deletion typically lands in Deleted Items. It could be more explicit about when not to use this tool versus alternatives like delete-outlook-contact, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explicitly stating it is a soft delete that moves to Deleted Items. No contradictions with annotations (destructiveHint: true). Adds valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a tip, no redundant information. Front-loaded with the core action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, with annotations already covering destructive nature, the description adds soft delete nuance, making it complete. No output schema needed for delete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described in the input schema. The description does not add extra parameter information, but the baseline for high coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes an Outlook email message by message ID, with the verb 'delete' matching the tool name. It specifies the action is a soft delete, distinguishing it from permanent deletion and other delete tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip provides explicit guidance on soft delete behavior and how to achieve permanent deletion, giving context on when to use. However, it does not compare with alternative delete methods or specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description complements the readOnlyHint annotation by stating that the tool lists all accounts and reflects accounts added mid-session via --login. This provides additional behavioral context beyond the annotation, such as dynamic account updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. It is front-loaded with the main purpose and includes essential usage guidance. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is complete. It covers what the tool does, when to use it, and a key behavioral detail about mid-session additions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema is fully covered. The description adds value by explaining the output (account emails) and the purpose, which is useful for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all Microsoft accounts configured in the server. It specifies the resource (accounts) and the action (list). It distinguishes itself from sibling tools like login, logout, select-account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to discover available account emails before making tool calls, providing clear usage context. It also notes that it reflects accounts added mid-session, but does not explicitly mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and destructiveHint annotations, the description explains the delta behavior (additions, deletions, updates) and expiration, adding valuable context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a tip section and front-loaded purpose, though somewhat lengthy; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (delta sync, 12 params, no output schema), the description covers the mechanism, usage pattern, and alternatives adequately, though return format is not detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description only minimally adds to parameter meaning (e.g., suggesting $select to limit fields), not significantly exceeding schema explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets event resources added, deleted, or updated in a calendarView of the primary calendar, distinguishing it from sibling tools like list-calendar-events and list-calendar-view-delta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip explains the incremental sync pattern, deltaLink usage, delta expiry after ~30 days, fallback on 410 Gone, and recommends list-calendar-view-delta for time-bounded views with delta semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral constraint beyond the annotations: only the role property is writable, and changing other properties requires delete/recreate. Annotations (readOnlyHint:false, destructiveHint:true) already indicate mutation and destructive potential, but the description adds the specific 'only role' limitation, which is valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a TIP section and uses a compact enumeration of roles. Every sentence carries useful information without redundancy. It is slightly dense but appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (nested body object, 5 params, no output schema), the description adequately covers the core purpose, writable fields, allowed values, and associated workflow. It does not explain return values, but no output schema exists and the description focuses on the key usage constraints, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (80%), so baseline is 3. The description adds semantic context beyond the schema by explicitly listing the allowed role enum values ('read' | 'write' | 'delegateWithoutPrivateEventAccess' | 'delegateWithPrivateEventAccess') and clarifying that only role is writable, which helps the agent understand the body parameter's constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Update my calendar permission' and immediately clarifies 'Changes the role (permission level) granted to an existing share recipient or delegate.' This distinguishes it from sibling tools like create-my-calendar-permission, delete-my-calendar-permission, and list-my-calendar-permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use and alternatives: 'Only the role property is writable — to change the recipient's email or other properties, delete and recreate via delete-my-calendar-permission + create-my-calendar-permission. Get the permission id via list-my-calendar-permissions.' This names exact alternative tools and workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false; the description builds on this by disclosing the conflictBehavior options ('rename' default, 'replace', 'fail'), which clarifies potential destructive overwrite behavior. It also specifies required body content (name and folder), adding valuable behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences plus a clearly marked tip. Every sentence provides essential information—purpose, required body fields, and conflict behavior—without filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with a nested body schema and no output schema, the description covers the core usage (required fields, conflict behavior) adequately. It doesn't mention permission requirements or return values, but the annotations and schema descriptions compensate for those gaps. The lack of explicit mention of the 'confirm' gate is minor since the schema covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 83% schema coverage, the schema handles most parameter descriptions. The description adds crucial semantics by stating that body must include 'name' and 'folder' fields and by explaining how @microsoft.graph.conflictBehavior controls name conflicts—information not present in the schema. This meaningfully supplements the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a OneDrive folder' and elaborates with 'Creates a new folder inside the specified drive item.' This is a specific verb+resource combination that distinguishes this tool from sibling file/drive tools like delete-onedrive-file or upload-file-content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool creates a subfolder in a specified drive item, requiring driveId and driveItemId. It gives usage tips about the body fields and conflict behavior, but does not explicitly name alternatives or exclusions. However, the context is sufficient for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond the annotations: the URL is short-lived and pre-authenticated, does not require an Authorization header, and streams bytes directly (no base64 encoding). It also lists unsupported scenarios. Annotations indicate readOnlyHint=true and openWorldHint=true, which are consistent with the description. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 6-7 sentences, well-structured with a clear flow: purpose, benefit, preference guidance, exceptions, and return info. It is informative but could be slightly more concise; however, it earns its sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description covers all necessary context: what it does, how to use it, when to use alternatives, unsupported types, and the return format. It addresses edge cases and provides complete guidance for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add much beyond what the schema already provides for the 'target' parameter. The schema itself includes a detailed explanation with examples, so the description's added value is minimal. Hence, score 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool resolves a short-lived, pre-authenticated download URL for Microsoft Graph binary content (drive/SharePoint file content). It uses a specific verb 'Resolve' and clearly identifies the resource. The description also distinguishes this tool from download-bytes, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Prefer this over download-bytes for any file above a few KB or any bulk download.' It also states when NOT to use it (mail file attachments and meeting recordings) and directs users to use download-bytes for those cases. This clear differentiation satisfies the dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), the description discloses that $select is not supported and will cause a 400 error, and recommends $expand=linkedResources. It also mentions the return format (body content, checklist items, linked resources). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, front-loaded with the main purpose. The tip and note are well-placed and avoid unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers what is returned (body, checklist, linked resources) and warns about unsupported $select. However, it does not address the fetchAllPages parameter contextually for a single-task read, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description adds value by clarifying that $select is not supported and $expand should be used for linked resources, which enhances parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the properties and relationships of a todoTask object' with specific verb and resource. It specifies it returns a single task, distinguishing it from list operations like 'list-todo-task-lists'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage (reading a single task) and includes a specific tip about $expand and a warning about unsupported $select. However, it does not explicitly compare with alternative tools like 'get-planner-task' or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations (destructiveHint: true). It specifies that only displayName is writable, that built-in lists cause errors, and gives the required body format. These details help the agent avoid common failures and understand the mutation's scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a single sentence stating the purpose, followed by a tip with essential usage details. Every line adds value, no redundant or vague statements. The front-loading of the purpose ensures quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested schema, destructive, no output schema), the description covers the core action, limitations, and ID retrieval. However, it does not describe the return value (likely the updated task list object), which is a minor gap. The annotations and tip largely compensate, making it nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, but the description adds critical semantic value: it clarifies that the body should contain only displayName (not other properties) and that todoTaskListId must be the id from list-todo-task-lists. This compensates for the schema's complexity and highlights the only writable field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates properties of a todoTaskList object and specifies it renames a task list. It distinguishes itself from sibling tools like create-todo-task-list and delete-todo-task-list by focusing on updates. The verb 'update' and resource 'todoTaskList' are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: only displayName is writable, built-in lists (Flagged emails, default Tasks) cannot be renamed, and how to obtain list IDs via list-todo-task-lists. It implicitly tells the agent when not to use this tool (for built-in lists) but does not explicitly state alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return value (newly created message with new id) and body format. Annotations already indicate write operation, so description adds useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with action, uses bullet/tip format effectively. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: action, parameters, return value, comparison to sibling. Could include more details on return type but sufficient given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value over schema: explains DestinationId format with examples (inbox, archive, junkemail), clarifies messageId parameter naming and origin, and mentions optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it copies a message to a folder, specifies destination via DestinationId, and distinguishes from move-mail-message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with move-mail-message: 'For moving instead of copying, use move-mail-message.' Provides tip on usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true and destructiveHint=false, but the description adds a crucial non-obvious behavior: recurring events are not expanded, only seriesMaster is returned. This goes beyond what annotations convey and is highly relevant to the agent's invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: a clear main description and an actionable tip. No filler; front-loaded with the key caveat. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, all thoroughly described in the schema, plus annotations for read-only behavior and the description's critical recurring-events caveat, the description provides enough context for an agent to select and invoke the tool effectively. No output schema exists, but the return is self-evident as a list of events.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with rich per-parameter descriptions (e.g., $top, $filter, $select, fetchAllPages). The tool description itself adds no new parameter-level meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb ('List') and resource ('events from one of the signed-in user's calendars, addressed by calendar ID'), distinguishing from sibling tools like list-calendar-events. The tip also references get-specific-calendar-view as an alternative, reinforcing the specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that recurring events are not expanded and directs the agent to use get-specific-calendar-view instead, providing a clear when-not and alternative. It also implies use when a specific calendar ID is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and not read-only. The description adds beyond annotations: moves event to Deleted Items, sends custom message, only organizer succeeds, recurrence handling via occurrence ID. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with key purpose first, then details, then a tip. Slightly verbose but front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers outcomes (cancellation message, event moved to Deleted Items), error cases, recurrence, and prerequisites (organizer only). Complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (80%). Description clarifies that body has optional Comment string and explains eventId usage. The tip repeats parameter info but adds value by summarizing body structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a meeting for the organizer only and sends a cancellation message. It distinguishes from delete-calendar-event by explaining that cancel shows 'Canceled' in attendees' calendars, and notes that attendees calling get a 400 error and should use decline-calendar-event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool vs alternatives: 'Use this instead of delete-calendar-event when you want attendees to see Canceled' and advises attendees to use decline-calendar-event. It also clarifies it is for organizers only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: writes to an absolute outputPath, never overwrites an existing file, and returns specific fields. It also clarifies that it handles authenticated content. There is no contradiction with annotations (readOnlyHint likely refers to no modification of source).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with core functionality, then use cases, constraints, and guidance. It is slightly verbose but each sentence adds value. Could be streamlined, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of downloading authenticated byte content, the description is comprehensive. It covers use cases, constraints (no overwrite, absolute path), return format, and sibling tool guidance. No output schema exists, but the description mentions return fields. The tool's role is fully explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions, but the tool description adds meaningful detail: for 'target', it lists common paths and caveats (e.g., meeting recordings should use get-meeting-recording-content if available); for 'outputPath', it clarifies absolute path requirement, parent directory existence, and no-overwrite policy. Baseline 3 due to 100% schema coverage, but extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as writing authenticated Microsoft Graph byte content to a local file, returning specific fields. It distinguishes the tool from siblings like 'download-bytes' (which returns base64) and 'get-download-url' (which returns a URL), and lists specific use cases (mail attachments, meeting recordings, profile photos, Teams hosted content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool and when to prefer alternatives. It notes that get-download-url is preferred for OneDrive/SharePoint content and that this tool is the only way to save mail attachments and meeting recordings. It also mentions that the tool is only available in stdio mode, not over HTTP.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds value by specifying it's a POST call (a read-only operation), explaining the response structure, and detailing MailTipsOptions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs with a helpful tip block. Every sentence serves a purpose: stating action, clarifying use case, and detailing parameters. No wasted words, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and rich annotations, the description fully answers what it does, when to use it, how to invoke it, and what to expect in return. No gaps given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema having 67% coverage, the description provides essential extra meaning: an example body structure, explanation of MailTipsOptions (comma-separated subset), and response content. This compensates for missing schema descriptions on EmailAddresses and MailTipsOptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets MailTips for recipients, explaining what MailTips are (OOF, quota, external, etc.) and how it works via a POST call. It distinguishes from sibling tools by specifying a unique use case (pre-send checks) not covered by other mail actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage guidance: 'before sending an email' and 'Use this to short-circuit urgent emails...or to warn before fanning out to a large DL.' It lacks explicit when-not-to-use or alternative tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: it discloses that expanding recurring events to occurrences, returns deltaLink, and works on primary calendar. No contradictions with readOnlyHint and destructiveHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear first sentence and a tip section. Informative but could be slightly more concise; however, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: initial params, deltaLink, recurring expansion, use case, and fetchAllPages behavior. No output schema but adequately describes return value (events + deltaLink).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining the process for required start/end date parameters and the role of deltaLink, which goes beyond individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets added/deleted/updated events in a calendarView of the primary calendar. Differentiates from sibling list-calendar-events-delta by noting it expands recurring events to individual occurrences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the delta sync process: initial call with start/end dates, subsequent calls with deltaLink. Provides tip for incremental sync within time window and recommends use for calendar UIs showing week/month views. Contrasts with alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Read-only. Nullable.' and details the returned metadata, aligning with annotations (readOnlyHint=true). It adds context about nullable nature and large file handling, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and concise overall, but the tip paragraph is lengthy. It could be slightly trimmed without losing key guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing returned fields. Combined with 100% parameter coverage and alternatives for file download, the description is fully complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds value by listing the output fields (name, size, etc.) not present in the input schema, giving the agent a clear picture of what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Gets metadata for a file or folder' and lists specific fields (name, size, etc.), clearly distinguishing it from sibling tools like get-download-url or list-folder-files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip provides explicit guidance on when to use this tool vs. alternatives: for large files use get-download-url/download-bytes, for small files use download-bytes. This clearly delineates usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses numerous behavioral traits beyond annotations: state tokens, delta links, expiration after ~30 days, pagination, and error handling (410). No contradictions with readOnlyHint=true and destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear purpose, technical details, then a tip block. First paragraph is somewhat verbose but necessary to explain the delta concept. Every sentence adds value, and structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given complexity: explains token flow, pagination, expiration, error handling, and parameter nuances. No output schema but description covers key response elements (deltaLink, nextLink). Sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond input schema: explains $top size guidelines, $count requirement for advanced filters, $expand limitations (only navigation properties, unsupported values ignored), changeType usage, and warnings. Schema coverage is 100% but description enriches each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets messages added, deleted, or updated in a specified folder. Distinguishes from sibling list-mail-folder-messages by emphasizing delta/incremental changes. The tip reinforces its purpose for incremental sync.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use: for incremental sync instead of full re-list. Mentions token-based flow, first call vs subsequent calls, and handling of 410 (start over). Provides clear context about pagination and delta links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, description details return format (contentType, encoding base64, contentLength, contentBytes) and warns about large file handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized: first sentence states purpose and return format, then lists use cases, then alternative guidance, then parameter explanation. Every sentence adds value without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers all needed information: what it does, how to use it (with examples), return format, and when to choose alternatives. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds extensive value by explaining the target parameter with concrete, diverse examples (drive paths, mail attachments, photo, Teams hosted content). This provides contextual meaning beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'download', resource 'binary content from Microsoft Graph', and lists numerous specific use cases (drive file, mail attachment, profile photo, Teams content, meeting recording). Distinguishes itself from sibling tools like get-download-url and download-bytes-to-file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use get-download-url for large drive/SharePoint files and get-meeting-recording-content for meeting recordings, providing clear when-to-use-alternatives guidance. Also states it is a single tool for any binary read, setting usage scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, destructiveHint) are complemented by detailed behavioral context: explains that $search and $filter cannot be combined, describes the body preview vs full body, and clarifies pagination behavior with @odata.nextLink. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, bullet points, and examples. Front-loaded with main function, then tips and critical notes. Every sentence provides value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 12 parameters and no output schema, the description is thorough: covers parameter interdependencies, best practices, common pitfalls, and references to sibling tools. Includes URL for further reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds significant value beyond schema: provides KQL syntax examples, explains when to set $count=true for advanced filters, and gives formatting rules for $search (double quotes).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists, searches, and filters Outlook email messages across all folders. It distinguishes itself from sibling tools like get-mail-message (full body retrieval) and list-mail-folder-messages (folder-specific), using specific verbs and resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: recommends $select to limit fields, explains when to use $search vs $filter, advises on pagination (small $top, then @odata.nextLink), and warns about fetchAllPages payload size. Includes critical formatting tips for $search and references to sibling tool get-mail-message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ms-365-mcp-server MCP server](https://glama.ai/mcp/servers/Softeria/ms-365-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Softeria/ms-365-mcp-server)

Score Badge

Copy to your README.md:

[![ms-365-mcp-server MCP server](https://glama.ai/mcp/servers/Softeria/ms-365-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Softeria/ms-365-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Softeria/ms-365-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server