Microsoft 365 MCP Server

Server Quality Checklist

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

Latest release: v0.149.1
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.
- 94 of 96 community issues answered or closed in the last 6 months
- 88 commits in the last 12 weeks
- Last stable release on September 3, 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?
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.
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?
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a write (readOnlyHint=false) and destructive (destructiveHint=true), and the description adds no behavioral context beyond that — no mention of confirm-gate interaction, idempotency, or side effects. For a create operation that modifies data, the description should at least acknowledge that creating the new object has persistent 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?
The single sentence is succinct and front-loaded, with no redundant filler. The brevity is a sign of under-specification, which is penalized in other dimensions, but as a structural matter it is appropriately terse for a single-sentence definition.
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, open-world tool with a deeply nested body schema and no output schema, one sentence is insufficient context. It doesn't say the bucket must belong to an existing plan, what happens if the client supplies a conflicting id, or what the caller should expect after a successful creation.
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 75% of parameters with descriptive text, including body, planId, confirm, and the nested task fields, so the schema itself carries most of the semantic weight. The description adds nothing about how the parameters combine (e.g., that the bucket needs a valid planId or that body is required).
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 a specific verb (Create) and resource (plannerBucket object) plainly, so an agent can identify what the action is. However, it is essentially a restatement of the tool name and provides no distinguishing detail about what a planner bucket is relative to other Planner 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?
Offers no guidance on when to invoke this tool instead of siblings like create-planner-task, list-plan-buckets, or update-planner-bucket. It also fails to mention the prerequisite context (e.g., an existing plan to attach the bucket to) or when the confirm gate applies.
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.
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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotation 'destructiveHint: true' because creating a calendar is typically not destructive. It also fails to mention any side effects, confirmation requirements, or the fact that a 'confirm' parameter may be required when the confirmation gate is enabled. No behavioral details beyond the basic action 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 concise, consisting of two sentences. It is well-structured with a clear statement followed by a helpful tip. No unnecessary words or redundancies.
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 essential idea of creating a calendar, it lacks context about required fields, typical usage patterns, or what happens after creation. The schema is very large, and the description offers only a minimal example. It is complete enough for a simple action but not fully comprehensive given the tool's 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?
The description provides a simple example of the body ({ name, color }) and lists valid color values, which adds some meaning beyond the schema. However, it does not clarify the purpose of the other parameters (confirm, includeHeaders, excludeResponse) or explain the structure of nested objects. The schema already describes most properties, so the incremental value is modest.
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') and the resource ('a new calendar for a user'). It is specific enough to distinguish from sibling tools like 'list-calendars' or 'update-calendar'.
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, nor any prerequisites or conditions. The description is purely declarative and does not help an agent decide between creating a calendar and other calendar operations.
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 does not disclose any side effects, confirmation requirements, or other behaviors beyond the annotation's destructiveHint flag. It adds no additional transparency beyond the metadata.
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 concise sentence that is well-structured and to the point, avoiding any unnecessary verbosity.
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 complex nested body object and the absence of an output schema, the description lacks contextual information about required properties, special considerations, or the intended use of the task creation. It is minimal and insufficient for complete understanding.
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?
The description adds no meaning to the parameters. While the schema has a coverage of 75%, the top-level body parameter is not described and the tool description does not mention any 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 action 'Create' and the resource 'plannerTask', which is specific enough to distinguish it from other create tools in the sibling list.
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 about when to use this tool versus alternatives, nor any context for its typical usage scenarios. The description is purely a one-liner without usage hints.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several important behaviors: the server decodes base64 before PUT, truncated base64 decodes to a truncated file with no error, and it overwrites existing files without warning. These go beyond the annotations' destructiveHint and provide critical risk information, though it stops short of covering all side effects.
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 first sentence is a vague fragment that does not convey purpose and could be removed. The tip is informative but the description would benefit from a clear verb-first summary and moving the tip into an optional note. As structured, it is under-specified and poorly 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?
Given the complexity (6 params, destructive operation), the description does a good job warning about overwrites and truncation and pointing to create-upload-session for large files. However, it does not describe the response/return value, prerequisites like authentication, or how the path format interacts with the driveItemId parameter, leaving 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?
The input schema has 100% description coverage, so the description adds only marginal value beyond it. It clarifies that 'body' is base64-encoded and mentions an alternative path format for new files, which is useful but not essential given the schema already explains each parameter.
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 opens with the noun phrase 'The content stream, if the item represents a file,' which does not clearly state an action. The tip implies the tool PUTs base64-encoded content to a drive item, but the primary description is vague and never explicitly says what the tool does. It also does not distinguish this tool from siblings in the main description.
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 advises using create-upload-session for large files, providing a clear alternative. It also gives a path format for new files, which is a direct usage instruction. However, it does not explicitly state the conditions for using this tool (e.g., small files, overwriting existing content) beyond implication.
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 signal a non-read-only, destructive mutation, so the description is not expected to repeat that. It adds the useful scoping detail of root vs other folder, though it does not mention idempotency, confirmation behavior, or side effects beyond what the confirm parameter already covers.
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 one concise, front-loaded sentence with no filler. It communicates the core action and target in under 20 words, and every word earns its place.
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 input schema is large and nested, and there is an overlapping sibling create-contact-in-folder, yet the description never explains how to target a non-root folder or what distinguishes this variant. There is also no output schema and no mention of return values or required body fields, leaving important call details to inference.
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 description adds no parameter-level meaning, but the schema carries 75% coverage, including rich descriptions for the nested body properties and the confirm/includeHeaders/excludeResponse parameters. Since the schema already documents the parameters sufficiently, the description does not need to restate them.
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 exact operation ('Add a contact') and the two target locations: the root Contacts folder or another contact folder's contacts endpoint. It is clear about the resource and action, but it does not explicitly distinguish this from the sibling create-contact-in-folder, so it is not fully differentiated.
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 on when to choose this tool over create-contact-in-folder or update-outlook-contact, and no mention of prerequisites or exclusions. The folder-target wording provides only a weak contextual hint for routing an agent.
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.
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 mutation nature is disclosed. The description adds the critical If-Match header requirement with a pointer to get-planner-bucket and includeHeaders=true, which is behavioral context beyond the annotations. However, it does not mention partial vs full update semantics, error behavior if the ETag is stale, or the confirm gate (though that is covered in the schema). It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: a clear purpose statement followed by a compact, high-value tip. It is front-loaded with the action and then provides a critical operational note. The phrasing is slightly awkward ('plannerbucket' without a space) but overall concise and efficient. It avoids unnecessary 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 tool's complexity (6 parameters, nested body object, destructive mutation), the description is minimal. It covers the essential If-Match requirement but omits update semantics (e.g., only provided fields are updated), what happens with conflicting ETags, and any prerequisites like existing bucket existence. However, the rich schema descriptions for parameters and the body partially compensate. An agent would need to rely heavily on the schema and external knowledge to call it 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 83%, meaning most parameters (If-Match, includeHeaders, excludeResponse, plannerBucketId) have descriptions in the schema. The body object is deeply nested with its own field descriptions. The tool description adds no new meaning for parameters; the If-Match tip merely repeats what the schema already says ('ETag value'). With high schema coverage, the baseline of 3 applies.
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 the properties of plannerbucket object.' This is a specific verb-resource pairing that distinguishes it from create/delete siblings by virtue of the word 'update'. However, it does not explicitly contrast with these alternatives, so it lacks strong 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 create-planner-bucket, delete-planner-bucket, or get-planner-bucket. It only includes a required-header tip, which is a how-to detail, not a usage context. There are no alternatives named, no conditions for selection, and no exclusions. This leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal that this is a mutating/destructive operation (readOnlyHint=false, destructiveHint=true), and the description adds little behavior beyond restating that it creates an event. The tip about not guessing recipient emails is useful workflow advice, but it does not clarify side effects such as invites being sent, permission requirements, or the confirmation 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 compact and front-loaded: the first sentence states the action and target, and the second adds a genuinely important guardrail. Every sentence earns its place, and there is no redundant filler or repeated field-level documentation.
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 create operation, the core target and key user-facing tip are present, and the rich input schema fills in event details. However, the tool is part of a large calendar-related sibling group, and the description does not clarify return values or side effects, and it relies on the agent inferring that the returned object will match the calendar event 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?
With 80% schema description coverage, the schema already documents most parameters well, so the baseline is 3. The description adds some value by clarifying valid calendar targets and calling out the need to use list-users for recipient emails rather than guessing, but it does not systematically improve the agent's understanding of the body parameter's required structure.
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 identifies the operation as creating a new event in a specific calendar and adds the useful scope that the calendar can be a user calendar or a Microsoft 365 group's default calendar. However, it does not explicitly distinguish itself from the sibling create-calendar-event tool, so an agent could struggle to know why this 'specific' variant exists.
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 functional context: it is used when you want to create an event in a user or M365 group calendar. However, it gives no explicit guidance about when to prefer this tool over create-calendar-event, update-specific-calendar-event, or other sibling calendar tools, and it does not state any 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 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 carry readOnlyHint=false and destructiveHint=true, and the description adds meaningful behavior on top: MIME-format sends are saved to Sent Items, and the JSON format supports file attachments in the same call. However, with destructiveHint=true and the irreversibility of an email send, one would expect an explicit acknowledgment of the irreversible/real-world side effect (e.g., confirmation-gate behavior connects to the confirm param, but only the schema explains it). No contradiction with annotations, but the safety-sensitive nature deserved a sentence.
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 writing is mostly tight and front-loaded with the primary verb, and the critical warning is visually separated. However, the 'To learn more... see here' link is a dead reference — the URL was stripped, leaving a dangling pointer that an agent cannot follow. The '💡 TIP: CRITICAL:' stacking is also redundant (a tip that is also critical). These small issues keep an otherwise compact description from being polished.
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 single-action tool with 4 parameters and no output schema, the description covers the two most critical behaviors (send, and the JSON-attachment constraint) plus a critical user-safety rule. Yet for a tool marked destructiveHint=true with a confirm-gate parameter, a brief note about the confirmation flow or the likely response shape would have made the description complete. Adequate but not comprehensive for the tool's 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?
At 75% schema coverage, the baseline is 3, and the description does not need to compensate heavily. The JSON/MIME format discussion adds marginal meaning to the 'body' parameter by telling the agent that attachments are only available in JSON mode. It does not, however, explain the distinction between the two remaining parameters (includeHeaders, excludeResponse) or add anything about the confirm gate, though those are reasonably self-describing 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 opens with a clear verb+resource ('Send the message specified in the request body') and adds the JSON/MIME format distinction that meaningfully scopes the tool. It differentiates from draft creation ('create a draft message to send later'), which helps an agent distinguish it from the many mail siblings. It loses a point because it never explicitly names sibling tools like send-draft-message or create-draft-email, leaving the agent to infer which sibling it means.
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 genuine when-not-to-use signal ('Alternatively, create a draft message to send later') and a highly actionable correctness tip about using list-users rather than guessing recipient addresses. However, the sibling space contains at least four near-cousins (send-draft-message, create-draft-email, forward-mail-message, reply-mail-message) and none are named or contrasted, so an agent navigating the directory gets no help choosing among them.
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 genuinely non-obvious behavior beyond the destructiveHint annotation: 'The event remains in the calendar as declined unless the user deletes it.' This tells the agent that declining does not remove the event, which is exactly the kind of side-effect an agent cannot infer from the schema. It does not contradict annotations and adds real value on top of the destructiveHint flag.
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 core purpose in the first sentence. The TIP section is somewhat redundant ('Declines a meeting invitation' repeats the opener) and the 'see Propose new meeting times' reference is a dangling link with no URL. Otherwise every sentence earns its place, particularly the persistence note.
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 5-parameter, nested-object tool with no output schema, the description covers the core action, the alternative-time proposal flow, and the post-decline state. It lacks prerequisites (the caller must be the invitee), doesn't mention what the organizer sees (e.g., that a decline response is sent when sendResponse is true), and offers no routing to accept/tentatively-accept siblings. Adequate for the happy path, with clear 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?
With 80% schema description coverage, the schema already documents eventId, confirm, includeHeaders, and excludeResponse. The description adds meaning by explaining that ProposedNewTime lets an invitee 'suggest an alternative time' and by giving a body usage example. However, the example uses camelCase keys (sendResponse, comment) while the schema declares PascalCase keys (SendResponse, Comment), which could mislead an agent constructing the body.
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 opens with a specific verb+resource pair: 'Decline invitation to the specified event in a user calendar.' The 'invitation' framing implicitly distinguishes it from siblings like cancel-calendar-event (organizer action) and accept/tentatively-accept-calendar-event. It stops short of naming the sibling it is not, so it misses the top score.
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 when-to-use or when-not-to-use guidance is given relative to accept-calendar-event, tentatively-accept-calendar-event, cancel-calendar-event, or delete-calendar-event, all of which are siblings. The only usage context is the conditional explanation of when proposedNewTime applies, which covers a sub-feature rather than tool selection. The invitee-vs-organizer distinction is left entirely to inference.
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?
Annotations already mark the tool as non-readOnly and destructive, so the description does not need to belabor that modifying mailbox settings has side effects. It does add useful context about supported formats for time zone and date/time values, but it does not explain what happens to existing settings that are omitted from the request or what the response will include.
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 includes useful example and format guidance, but it is not tightly written. The 'TIP' sentence largely restates the tool name, the status values duplicate the schema enum, and 'as shown in example 2 below' refers to content that is not present, adding unnecessary noise.
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 tool with nested objects and no output schema, the description provides one strong common-use example but insufficient general coverage of other settings in the body. It does not describe the response format, behavior when partial settings are updated, or relationship to get-mailboxSettings, leaving the agent to rely on the schema for 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?
Schema coverage is 75%, and the description adds real value beyond the schema by explaining short date/time format constraints, Windows/IANA time zone requirements, and providing a concrete automaticRepliesSetting JSON example with valid statuses. It does not cover all nested fields like workingHours or language, but the schema already describes those reasonably well.
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 opens with specific verbs ('Enable, configure, or disable') tied to mailbox settings, which makes the operation clear and distinguishes it from read-only siblings like get-mailbox-settings. However, it does not explicitly enumerate all the settings it can update, and its sibling differentiation is only implied by the name.
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 common use case ('configure Out-of-Office') and a concrete body example, which helps an agent understand a realistic invocation. It does not explicitly state when to choose this tool over alternatives, nor does it mention related reading tool like get-mailbox-settings, so the usage guidance remains implicit.
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?
Annotations already mark it as destructive, so the key behavioral disclosure is the attendee warning about replacement of the entire list. This is valuable, non-obvious context about how a mutation behaves and goes beyond the schema and declarations.
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 and the key warnings are front-highlighted, but the lead sentence simply repeats the tool name. The warnings are useful and compact, so overall the structure is acceptable with minimal 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 schema and annotations cover the required parameters and mutating/destructive nature. Still, the description omits broader context such as how partial body updates interact with existing fields, confirmation requirements, or how this tool differs from update-calendar-event. It's adequate but not 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 high (83%), so the baseline is 3. The description adds useful semantics for the attendees list: don't guess emails, use list-users, and supply all existing attendees. This helps the agent construct a correct body even though the schema already documents the attendee shape.
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. However, it barely goes beyond the tool name and does not differentiate itself from the similarly named sibling update-calendar-event, so the 'specific' distinction is left for the agent to infer.
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 given about when to choose this tool over the very similar update-calendar-event, nor when not to use it. The list-users tip is a useful prerequisite but does not explain the tool's selection criteria or exclude 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?
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive (destructiveHint=true) and not read-only, so the description's job is lighter. The tip about emailAddresses being replaced entirely adds valuable non-obvious behavioral context beyond what annotations or the schema description 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?
Two short sentences with no filler. The core purpose is stated first, and the critical gotcha is placed immediately after, making the most important operational detail easy to notice.
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 main non-obvious behavior but remains minimal for a mutation tool with a large nested body schema. It does not explicitly state whether omitted properties are preserved or whether the operation is a partial update, and there is no output schema to clarify the response shape.
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 (80%), so the baseline is 3. The description adds meaningful semantics for the emailAddresses parameter by warning that the array is wholly replaced, which is not stated in the schema's own parameter description.
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 a clear verb ('Update') and resource ('contact object'), which distinguishes it from create/get/delete contact siblings. It does not explicitly differentiate from update-contact-folder, but the resource is specific enough for an agent to disambiguate.
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 create-outlook-contact, delete-outlook-contact, or get-outlook-contact. There is also no mention of prerequisites or cases where an update would be inappropriate.
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?
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 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 indicate readOnlyHint=false and destructiveHint=true, so the description doesn't need to repeat that it mutates state. It adds context about the proposedNewTime mechanism and the sendResponse/comment fields, which is useful. However, it does not disclose side effects like sending a response or that the event is modified in the calendar. Given the annotations already cover safety, this is acceptable but could be richer.
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 core action is front-loaded in the first sentence. The tip paragraph is an efficient addition with a concrete example. No fluff, but the description is not overly brief; it earns each sentence. Slightly verbose with the second paragraph, but it adds practical 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?
The tool has multiple nested parameters and no output schema. The description does not explain return values or error behavior, which agents might need. However, given the similarity to other calendar event tools, the response format may be assumed. The confirm gate and headers/flags are described in the schema, so the description doesn't need to repeat them. Still, a brief note on what to expect in response 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 80%, so the schema already documents most parameters. The description adds a concrete example for the body object in the tip, but this largely duplicates schema content. It does not clarify the 'confirm' parameter beyond what the schema states (which already explains when it is required). 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?
States a clear action ('Tentatively accept') on a specific resource ('the specified event in a user calendar'). The name itself differentiates from siblings like accept-calendar-event and decline-calendar-event, and the description reinforces this by focusing on tentative acceptance and optional proposal.
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 for using the tool (tentatively accepting an event) and mentions the optional proposal flow. Does not explicitly contrast with alternatives (e.g., 'use accept-calendar-event for final acceptance'), but the action is self-evident from the name and description. The tip gives concrete examples of body parameters, enhancing usability.
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?
The annotations already mark this as destructive (destructiveHint=true) and read-only=false, so the description doesn't need to restate mutation. It adds some transparency by noting that subject/body/recipients edits apply to a draft, but it does not disclose other side effects such as permanence of changes, potential confirm gate behavior, or that some fields may be read-only.
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?
A single sentence that front-loads the action and resource, then provides illustrative use cases. No wasted words or redundant repetition of schema 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 mutation tool with a large nested body schema and no output schema, the description is adequate but not rich. It explains common use cases but omits important operational context such as the confirm gate (covered in schema but not description), the fact that messageId is required, and the distinction between draft vs sent message update constraints beyond the draft mention.
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 schema already documents most parameters. The description adds value by mapping examples (isRead, flag, categories, importance, subject, body, recipients) to the 'body' parameter, but it doesn't go beyond what a careful agent could infer from 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 ('Update'), the resource ('existing Outlook email message'), and the key method ('by its message ID'). It lists concrete examples of updatable fields (isRead, flag, categories, importance) and even distinguishes draft-specific edits, making the tool's purpose unmistakable and distinct from siblings like delete-mail-message or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use when you need to modify an existing Outlook message's properties. It does not explicitly name alternative tools or state when not to use it, but the context is strong enough that the agent can infer the right scenario.
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 readOnlyHint=false and destructiveHint=true. The description adds transparency about the under-3MB constraint, the exact error on truncated base64, and the required @odata.type body structure. It does not mention the confirm parameter or any side effects, but it goes beyond annotations by explaining failure modes and size limitations.
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 malformed sentence: 'An attachment can be one of the following types: All these types...' It appears to cut off and doesn't list the types, causing confusion. The rest is efficient, but the structural issue reduces 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?
The description covers the main usage context (size threshold, base64 format, example body) but lacks information about what the tool returns on success or how the messageId is used. It doesn't mention that it adds to a specific message, though that is implied. The incomplete type list also leaves a 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 80%, so baseline is 3. The description adds value by giving an example body structure with @odata.type and contentBytes, and emphasizing that contentBytes must be verbatim base64. This clarifies the key parameter beyond what the schema provides, especially since the body object schema is generic with additionalProperties.
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 attachment. It distinguishes from the upload-session sibling by size threshold. However, the sentence 'An attachment can be one of the following types' is incomplete and fails to list the actual types, which slightly weakens the purpose. The mention of 'messageId' is only in the schema, not the description.
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 provides usage guidelines: it states this is the only path for attachments under 3MB and directs to create-mail-attachment-upload-session for larger sizes. It also gives a critical tip about contentBytes being complete base64 to avoid failure, which is specific 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?
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations mark this as destructiveHint: true, but the description describes a creation operation ('Add a contact') which is not destructive. This contradiction obscures the actual side effects. The description also does not disclose any other behavioral traits such as required permissions or response behavior beyond what the schema already states, so transparency is poor.
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 well-structured, consisting of two concise sentences plus a brief tip. It avoids redundancy and front-loads the core action and target, followed by usage differentiation and a retrieval hint. No filler or unnecessary details are present.
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 covers the essential context: what the tool does, when to use it over the alternative, and how to supply the necessary parameters. It lacks explicit mention of success/failure response or side effects, but given the simplicity and existing schema documentation, it is nearly complete. The contradiction with the destructive hint slightly reduces 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 description adds meaning to the 'contactFolderId' parameter by clarifying the naming convention ('Pass it under the name 'contactFolderId', not as 'id'') and referencing the source of the value. It also summarizes the 'body' parameter as a contact resource. However, for the 'confirm', 'includeHeaders', and 'excludeResponse' parameters, the description offers no additional insight beyond the schema descriptions, which are already present.
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 ('Add'), the target ('a contact'), and the location ('to the root Contacts folder or to the contacts endpoint of another contact folder'). It also names the sibling tool it differentiates from, making the 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?
It explicitly contrasts with create-outlook-contact, stating when to use this tool versus the alternative ('writes to the default folder only; use this when organizing contacts into named folders'). It also provides a retrieval hint ('Get 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 include destructiveHint=true and readOnlyHint=false, signaling a mutation. The description adds valuable context that no email is actually sent, which is not present in annotations. This helps the agent understand the side effect boundary (creation vs. sending) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The tip repeats 'Create a forward draft' verbatim, adding slight redundancy, but otherwise the structure is efficient. No wasted sentences beyond the repetition.
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 deals with a complex body object and lacks an output schema. The description does not explain what the body should contain or how to reference the original message, though the schema provides some coverage. Given the complexity, more guidance would help, but the description is not severely lacking, so a 3 is fair.
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%, which is high, so the schema documents most parameters (e.g., messageId, confirm, includeHeaders, excludeResponse) with descriptions. However, the description adds no further parameter explanation, and the complex body object (with Comment, Message, ToRecipients) has no description in the schema either. Since the description does not compensate for gaps, a 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: 'Create a forward draft', and immediately clarifies that it does not send. This distinguishes it from sibling tools like forward-mail-message, which actually sends, and create-reply-draft, which is a different kind of draft. The verb and resource 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip provides a clear use case: 'Useful when user wants to review before sending.' This implies when to choose this tool over forward-mail-message, but it does not explicitly name alternatives or state when not to use it. It gives context but lacks explicit exclusions or comparisons.
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 that the tool returns an upload URL for subsequent PUT operations, clarifying that it does not upload the file itself. This adds behavioral context beyond the annotations (which only mark destructiveHint), though it does not elaborate on confirmation requirements or side effects.
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 verbose and repetitive, restating the same size threshold and upload flow multiple times, including a redundant TIP section. This hurts clarity and readability, making it less concise than ideal.
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 core flow (create session, get URL, then PUT) but omits mention of the confirm parameter's role and confirmation requirements, which is relevant given the destructiveHint annotation and the schema. It is sufficient for basic use but lacks completeness for a complex multi-step 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 schema already provides detailed descriptions for the body, messageId, and confirm parameters, with 80% coverage. The description does not add new parameter-specific semantics; it only reiterates file size limits that relate to the overall usage rather than individual 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 tool creates an upload session for attaching a file to an Outlook item (message or event). It specifies the target resource and the unique action (creating a session), and distinguishes it from the alternative for smaller files (add-mail-attachment).
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 gives usage criteria: files between 3 MB and 150 MB should use this tool, while smaller files should use the POST operation on attachments. This provides clear when-to-use vs. when-not-to-use guidance, including a named alternative.
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, but the description adds valuable behavioral context: it warns that supplying Message.body replaces the whole draft body (quoted history not included), explains the 400 error risk, and notes signatures are added by Outlook client, not Graph. It also describes the draft lifecycle (can update later, send later). This exceeds the annotation minimalism by providing concrete operational constraints and risks.
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 comprehensive with structured bullet points and a prominent tip box. It is front-loaded with the main action and format distinction. While it's a bit long, the length is justified by the complexity of the operation and the multiple format-specific rules. No irrelevant fluff; all content is actionable.
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 that the tool is complex (two formats, multiple constraints, RFC details) and has no output schema, the description covers the essential operational details: how to specify the reply content, the mutual exclusivity rule, the MIME encoding requirement, the handling of replyTo, the behavior of the body replacement, and the absence of signature handling. It also mentions the option to send later. This is complete enough for an agent to correctly invoke the tool without needing additional info.
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 already documents parameters like messageId and confirm. The description adds meaningful semantics for 'body' parameter: explains the comment/body mutual exclusivity, the difference in MIME format (base64 encoded), and the HTML tip. However, it doesn't fully document all parameters, but the schema is largely self-explanatory. A score of 3 is appropriate as the description adds value but doesn't fully compensate for the remaining 20% coverage gap.
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 draft to reply to a message's sender, with formats JSON or MIME. It distinguishes from siblings like create-reply-all-draft and reply-mail-message by focusing on draft creation for the sender. However, it doesn't explicitly name those siblings, so differentiation is mainly implicit.
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 detailed guidance on when to use JSON vs MIME, specifically the rule about replyTo vs from recipients, and the constraint that comment and body cannot both be specified. It implies usage for drafting a reply, and mentions 'Alternatively, reply to a message in a single operation' implying a sibling operation exists, but doesn't name it. Clear context but lacks explicit exclusions of 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?
Beyond annotations (readOnlyHint=false, destructiveHint=true), the description discloses that the server does not perform the PUT—the caller must upload bytes to the returned URL. It also notes the body is optional (though this contradicts the schema) and provides a conflictBehavior example, adding meaningful 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 compact and well-structured. It front-loads the purpose, uses a tip to highlight the key use case, and includes only essential details about behavior and body example. No redundant or filler 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?
The description covers the core purpose, use case, and the critical PUT behavior. However, the erroneous 'optional' body representation introduces a reliability gap, and it does not address generic parameters like confirm, includeHeaders, or excludeResponse. These omissions, combined with the contradiction, leave it incomplete for a tool with this many parameters and complex body schema.
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 high (83%), so the baseline is 3, but the description directly contradicts the schema by stating 'Body (optional)' while the input schema lists body as required. This misleading statement could cause the agent to omit a required parameter. The conflictBehavior example is useful, but the false optionality is a severe flaw.
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 an upload session' and explains it returns a pre-authenticated uploadUrl for large file uploads. It distinguishes itself from the Outlook attachment upload session by noting no size limit and no minimum, making the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends this tool for large file uploads and contrasts it with the Outlook attachment session. It also gives an example path for new files. However, it does not mention when to prefer it over other upload tools like upload-file-content, so the alternatives are only partially covered.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true. The description adds valuable behavioral context: the If-Match header requirement and the 412 error condition, which is a critical behavioral trait not captured by annotations. It also explains the priority value mapping. The description doesn't contradict annotations. It adds meaningful behavioral disclosure beyond what annotations provide, though it could mention that this is a PATCH operation that only updates specified fields.
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 and front-loaded with the core purpose. The critical If-Match tip is prominently placed with a 💡 emoji and CRITICAL label. The priority values are listed compactly. The description is efficient with no wasted words, though the emoji and formatting could be seen as slightly informal for a tool description. Overall, it's well-structured and 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?
For a mutation tool with destructiveHint=true and no output schema, the description covers the critical operational requirements: the If-Match header, the error condition, and the priority mapping. It doesn't explain what the response looks like, but with no output schema, that's less critical. It could mention that only specified properties are updated (PATCH semantics) and that read-only properties should not be included. The description is largely complete for an agent to call this tool correctly, with minor gaps around PATCH semantics and response format.
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 83%, which is high. The description adds value for the If-Match parameter by explaining the ETag requirement and how to obtain it. It also explains priority values in the description, which complements the schema's priority description. The plannerTaskId parameter has a helpful note in the schema about passing it as 'plannerTaskId' not 'id', which is good. The description adds the critical If-Match context that the schema alone doesn't provide, so it compensates well for the 17% gap.
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 a clear verb and resource: 'Update the properties of plannerTask object.' It distinguishes this from sibling tools like create-planner-task and get-planner-task by the verb. However, it doesn't explicitly differentiate from update-planner-task-details, which is a close sibling that also updates planner task properties. The description is clear but could be more specific about which properties are updated (the main task object vs. the details 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?
The description provides critical usage guidance: it explains the If-Match header requirement, the 412 error if missing, and how to get the ETag (from get-planner-task with includeHeaders=true). It also explains priority values. However, it doesn't explicitly state when to use this tool vs. update-planner-task-details, which is a significant sibling that also updates planner task properties. The guidance is strong for the If-Match requirement but lacks explicit alternative routing.
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 signal a mutating readOnlyHint=false and destructiveHint=true, so the bar is lower. Beyond that, the description discloses the critical non-obvious behavior 'saved, not sent' — an agent might otherwise assume the call sends the email. This is a genuinely valuable behavioral disclosure. Remaining gaps are minor: no mention of return value, errors, or the confirm gate, but the confirm gate is documented 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, with the core purpose front-loaded first and the routing guidance placed last. The second sentence listing fields is mildly redundant with the rich schema, but it is still helpful as a quick summary of what the caller should worry about. No filler or repetition of annotation content.
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 a large nested input schema and no output schema, the description covers the essential aspects: what is created, where it lands, what fields matter, and the saved-not-sent behavior. The main omission is that there is no explicit note about what the call returns (e.g., the created message with its id), which is useful since the output schema is absent.
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 most parameters are already documented inside the input schema itself. The description adds the context that subject, body, toRecipients, ccRecipients, and importance are the fields the caller would typically populate, but doesn't explain structural concepts such as recipient shapes or content type. That is a small reinforcement, not a substantial addition, so the 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 states a clear verb (create) plus a precise resource (a draft Outlook message in the signed-in user's Drafts folder) and enumerates which fields can be set. It also separates itself from send-oriented tools, so an agent can distinguish it from siblings such as send-mail, send-draft-message, and create-reply-draft without opening their schemas.
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 third sentence explicitly routes the agent: 'The draft is saved, not sent — use send-mail to send a message directly, or send the draft afterwards.' That names the primary alternative with the selecting condition (the distinction between creating vs. sending). The only gap is that it doesn't name send-draft-message explicitly as the specific tool to send the draft afterwards, nor does it mention the forward/reply draft siblings, leaving a small part of the routing to inference.
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 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint and the confirm parameter explains the confirmation gate. The description does not contradict annotations and adds some behavioral context by explaining how to perform move/rename, but it does not go beyond what annotations provide, such as noting that moving can change permissions or that renaming may affect shared links.
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 and front-loaded, with the core purpose first followed by a helpful tip. The emoji and formatting add visual distinction, though it could be slightly more structured, but overall it's 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 complexity of the schema and the presence of the confirm parameter, the description is complete enough. It explains the key operations and the confirm parameter is described in the schema. No output schema exists, but the return values are standard for such operations and are implied.
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, but the description adds critical meaning by explaining that to move you must provide parentReference with the target folder's id and to rename you provide a new name. This is essential guidance that goes beyond the schema's generic 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 tool moves or renames a OneDrive item, and the tip explicitly explains how to do each operation. This distinguishes it from sibling tools like copy-drive-item and delete-onedrive-file.
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 on when to use each operation, but does not explicitly state when not to use this tool or mention alternatives. However, the tip is practical and gives the necessary context for typical usage 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?
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 already indicate a write operation (readOnlyHint: false) and destructiveHint: true, so the bar is lower. The description adds the effect (shares primary calendar or delegates) and provides an example body, plus the return value includes an id for later modifications. 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?
Two concise sentences plus a tip. The purpose is front-loaded, and the tip provides a concrete example and return information without unnecessary verbosity. 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?
Covers purpose, example body, return value, and relationship to update/delete siblings. It doesn't explicitly state that the tool targets the user's primary calendar only, but that is implied by the naming convention (create-my-calendar-permission) and sibling tools. No output schema, but the return is described adequately.
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 description doesn't need to carry the full burden. The tip provides an example body with typical role values, but the enumerated roles listed are an incomplete subset of the schema's full enum (missing 'none', 'freeBusyRead', etc.), which could slightly mislead. However, the schema itself has the full list, so this is not a major issue.
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 a specific verb and resource: 'Create a calendarPermission resource to specify the identity and role of the user with whom the specified calendar is being shared or delegated.' It distinguishes itself from update/delete siblings by mentioning the returned id is used for those operations. The tip clarifies it shares the user's primary calendar or sets up a delegate.
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 explains when to use the tool (sharing primary calendar, delegating) and directs the agent to use list-users to resolve email addresses. It also notes the return id is used by update and delete tools, providing chaining context. It doesn't explicitly state when not to use, but the intent 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 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 signal readOnlyHint=false and destructiveHint=true, so the description does not need to restate that this mutates data. It adds the scoping context of requiring a specific todoTaskListId, which is useful. However, it does not describe confirmation-gate behavior or response characteristics, though the confirm parameter in the schema covers part of that.
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: the first sentence states the action, and the tip adds the most useful usage details without restating the verbose schema. Every line 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?
For a task-creation tool with a complex nested body schema, the description covers the required call pattern and the main optional fields at the right level of detail. It does not explain return values, but that is not mandatory here. It could be slightly more explicit about confirmation behavior, but the confirm parameter description already handles that.
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 tip distills the large body schema into an actionable template: 'Body: { title: "..." }; optional dueDateTime, reminderDateTime, importance, body (notes), recurrence, categories.' It also tells the agent to source todoTaskListId from list-todo-task-lists, adding meaning beyond the raw schema. The remaining parameters (confirm, includeHeaders, excludeResponse) are left to the schema, but they are not central to calling the tool.
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 and resource: 'Create a new task object in a specified todoTaskList.' It clearly distinguishes this from sibling tools like update-todo-task, delete-todo-task, and create-todo-task-list, and reinforces the Microsoft To Do context in 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 actionable context: it tells the agent that a todoTaskListId is required and where to get it from (list-todo-task-lists). It does not explicitly call out alternatives or exclusions, but the create-vs-update/delete distinction is clear from the wording.
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 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?
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false, so the description's update semantics are consistent. It adds a useful constraint about the default calendar's name, 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 concise and front-loaded with the core action, followed by a helpful tip and a key constraint. 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?
Given the rich schema and annotations, the description is sufficient for an agent to call the tool correctly. It covers the primary usage example and a critical limitation, while the schema handles detailed field documentation. The lack of output schema is not a gap since responses aren't described.
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 an example body object, clarifying how to use the 'body' parameter. It also highlights the limitation on renaming the default calendar, which is not obvious from the schema alone.
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 a calendar's properties, with a concrete example (Body: { name: 'New Name', color: 'lightBlue' }). It implicitly distinguishes from sibling tools like update-calendar-event and create-calendar by targeting the calendar resource itself.
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 usage tip and a constraint (cannot update the default calendar's name) but doesn't explicitly guide when to use this vs alternatives like create-calendar or delete-calendar. No mention of when to defer to other tools for operations like permissions.
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?
Even though annotations already mark this as destructive/non-read-only, the description adds genuine behavioral value: the 4 MB size ceiling, the fact that a truncated base64 payload is written 'without error' so the caller must validate, the JPEG-only constraint, server-side decoding behavior, and the auto-generated thumbnails with exact pixel sizes. This makes failure modes and side effects far more predictable.
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?
At ~146 words the text is longer than average, but it is efficiently structured with a lead paragraph, a tip, and a retrieval hint, and almost every clause earns its place. The 4 MB limit is mentioned twice and the guidance could be slightly tightened, but it remains scannable 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?
For a destructive write tool with no output schema, the description covers all the key operational aspects: expected format, size caps, error behavior, permissions, and the companion read operation. The only substantive gap is the unresolved scope confusion (tenant-wide entity vs. signed-in user), plus little clarity on the response shape beyond the confirm-gate error.
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 already-rich per-parameter documentation (e.g., `confirm` explains the gate and error contract). The description supplements this by explaining what the base64 payload becomes on the server (decoded to raw bytes, PUT via Graph), warns about large-string risk, and reinforces JPEG/4MB validation rules—adding context around the schema rather than repeating it.
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 opens with a clear verb-resource-scope pattern ('Update the photo for the specified contact, group, team, or user') that immediately distinguishes it from sibling tools. However, this scope statement conflicts with the tip, which says it uploads 'for the signed-in user'—and the schema exposes no entity-ID parameter—so an agent might be misled about targeting arbitrary entities. Minor internal redundancy with '4 MB' stated twice.
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?
Excellent guidance: it explicitly names the sibling `download-bytes` with a full example target for the inverse operation, and it flags the ProfilePhoto.ReadWrite.All permission as a more granular alternative for work/school accounts. It does not, however, address when to choose this over other update/upload siblings (e.g., upload-file-content), leaving some comparison gaps.
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?
The description states that Outlook carries out the specified actions when an incoming message meets the conditions, which clarifies the operational behavior. Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutation, and the description aligns without contradiction. It does not elaborate on side effects or permanence beyond the core behavior, but annotations cover 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, a tip section, and a sample body. It is not overly verbose and front-loads the core purpose. The inclusion of an example is justified given the complexity of the body object, and the formatting with a line break and emoji improves readability.
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 tool with multiple nested objects and many condition/action properties, the description provides a sample body and lists the available actions, which is helpful. The schema extensively documents individual properties, so the description does not need to repeat all that. However, it does not mention what the tool returns on success (e.g., the created messageRule object), which could be a minor gap since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 80% of parameters with descriptions, so the baseline is high. The description adds a practical example body showing how to structure displayName, sequence, isEnabled, conditions, and actions, which is not in the schema. It also clarifies that mailFolderId must be passed under that name, not as 'id', and points to list-mail-folders for obtaining it, adding semantic clarity 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 (messageRule object), and the context (incoming messages in the user's Inbox). It distinguishes itself from sibling tools like update-mail-rule and delete-mail-rule by focusing on creation and the conditions/actions involved. The verb-resource pairing 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool, including a tip to use the Inbox folder ID from list-mail-folders for inbox rules. It also includes a concrete body example with required fields, which helps the agent construct a valid request. However, it does not explicitly contrast with alternatives like update-mail-rule or state scenarios where this tool should not be used.
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?
The annotations already flag this as a non-read-only, destructive-capable write operation, and the description adds useful behavioral details: the body shape is { displayName: 'My new list' }, the returned fields include id/displayName/isOwner/isShared/wellknownListName, and user-created lists get wellknownListName 'none'. 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 compact and front-loaded with the most useful information. The only mild redundancy is the opening 'Create a new lists object', which echoes the title and is less precise than the tip that follows, but overall every sentence 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?
Even without an output schema, the description states what the tool returns and what input is required, which makes it largely complete for a simple creation tool. It does not explain the confirm parameter behavior, but that is fully documented in the input schema itself.
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 much of the parameter meaning is already documented. The description still adds value by explicitly providing the required body example, { displayName: 'My new list' }, and explaining what the returned wellknownListName will be, which is more practical than 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 the action — 'Creates a new Microsoft To Do task list' — and explains what that means via the app-sidebar analogy. It differentiates from create-todo-task by explicitly saying to pair with that tool to populate the list, so an agent can tell them apart.
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 actionable usage context: built-in lists like 'Tasks' and 'Flagged emails' already exist and cannot be re-created, and the tool should be paired with create-todo-task to add tasks. It does not explicitly discuss when to use update-todo-task-list instead, but the create-vs-update distinction 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?
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 the safety profile is covered. The description adds useful behavioral context by stating the return is the complete original message with headers and encoded attachments, and that the MIME stream comes back as text.
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 front-loaded and compact, but the tip paragraph partly repeats the first sentence ('raw RFC 5322 MIME content', 'Returns the MIME stream as text'). The use case and message-id workflow add value; the redundancy keeps it from a 4.
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 read-only single-resource retrieval tool, the description fully explains what is returned, why to use it, and how to obtain the required message ID. All optional parameters are documented in the schema, and no output schema exists, so the explicit "returns MIME stream as text" statement 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 description coverage is 100%, so the description does not need to re-explain parameters. It adds one useful workflow hint beyond the schema: 'Find the message id with list-mail-messages first.' This is above the baseline for fully schema-covered 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?
States a specific verb and resource: 'Download the raw MIME source (RFC 822 .eml content) of an Outlook email message by its message ID.' The mention of raw MIME vs the sibling get-mail-message clearly distinguishes it from a normal message fetch.
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 gives a use case: 'Use this when archiving an email to disk preserving all original headers, body, and inline-encoded attachments.' It also tells the agent to find the message id with list-mail-messages first. It does not explicitly mention when not to use it or contrast with get-mail-message, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
The description adds meaningful behavioral details beyond the annotations: it states the message is saved in Sent Items, explains replyTo precedence per RFC 2822, and warns about HTTP 400 when both comment and body are supplied. This complements the destructiveHint=true annotation without contradicting 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 well-organized into JSON and MIME sections with bullet points, making the two modes easy to scan. The tip is useful but slightly informal and partially redundant with the body/comment guidance, so it is not perfectly concise.
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, destructive mail-sending tool with no output schema, the description covers the key behaviors: format selection, required parameters, error conditions, replyTo semantics, MIME encoding, and the Sent Items side effect. It does not describe the response shape, but no output schema exists and the schema already documents the generic response flags.
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%, and the description adds important parameter-level semantics: the Comment/Message body conflict, replyTo handling, MIME base64 requirement, and attachment/S-MIME guidance. It does not explain includeHeaders or excludeResponse, but those are adequately 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 opens with a specific verb and resource: 'Reply to all recipients of a message', which clearly distinguishes it from single-recipient reply and forward tools. It also names the two supported formats (JSON and MIME), so an agent knows exactly what operation this tool performs.
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 concrete usage context for both JSON and MIME modes, including constraints like the comment/body mutual exclusivity and base64 encoding for MIME. It also names the draft alternative ('create a draft to reply-all to a message and send it later'), but it does not explicitly contrast with reply-mail-message or forward-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 mark the operation as non-read-only and destructive. The description adds meaningful behavioral details: specifying both comment and body returns HTTP 400, replies route to replyTo rather than from per RFC 2822, and the method saves the message in the Sent Items folder. It does not overpromise or contradict the destructiveHint annotation.
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 longer than average but earns its length by covering two distinct input formats and a side effect. It is front-loaded with the core purpose, uses bullet separation for JSON and MIME cases, and ends with a genuinely useful formatting tip. Some MIME instructions could be tighter, but nothing is redundant.
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 nested schema objects and no output schema, the description covers the key invocation decisions: format choice, required messageId routing, comment/body exclusivity, replyTo behavior, Sent Items side effect, and the draft alternative. It is missing only explicit return-value expectations and a clearer MIME-to-schema mapping, but it is sufficient for correct invocation in most cases.
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 on top by explaining the critical constraint: specify either a comment or the body property, not both. The tip that 'comment' is the reply text helps disambiguate the schema's nested body object. MIME content placement is somewhat inferred rather than explicitly mapped to a schema field, which prevents a 5.
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 a specific verb and resource: 'Reply to the sender of a message,' which immediately distinguishes this from reply-all-mail-message, forward-mail-message, and draft-creation siblings. It also adds the JSON/MIME dual-mode scope, making the tool's behavior unambiguous beyond the name alone.
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: send a reply now versus 'alternatively, create a draft to reply to an existing message and send it later.' It also explains the JSON/MIME branches and the mutual-exclusion rule. It does not explicitly name reply-all-mail-message as the alternative for replying to all recipients, so guidance is strong but not fully exhaustive.
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 this is a mutating/destructive action. The description adds useful behavioral context by explaining that this is a partial update ('send only the properties to change') and that only writable properties should be modified. It also gives a concrete example of disabling a rule, which helps the agent predict the mutation's effect.
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 core action. The tip section is useful, though there is minor redundancy: 'Updates an existing message rule' largely restates 'Change writable properties on a messageRule object.' Overall, every major sentence 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?
For a complex nested-body operation with no output schema, the description provides enough practical context: it explains partial update semantics, where to get the inbox folder ID, and shows a realistic minimal payload. It does not explain how the updated rule is returned, but the schema and annotations cover the input side well, and the operation is conventional.
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 at 83%, so the schema does the heavy lifting. The description still adds value by clarifying the body parameter semantics: send only changed properties, and provides a concrete common payload shape like { isEnabled: false }. It also gives guidance on sourcing the mailFolderId from list-mail-folders.
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 and resource: 'Change writable properties on a messageRule object and save the changes.' It also reinforces the intent by saying 'Updates an existing message rule,' which clearly distinguishes this from sibling tools like create-mail-rule, delete-mail-rule, and list-mail-rules.
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: use the Inbox folder ID from list-mail-folders, send only the properties to change, and gives a common use case for disabling a rule. It does not explicitly say 'use create-mail-rule for new rules' or 'use delete-mail-rule for removal,' but 'existing message rule' implies this distinction clearly 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?
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 mark this as mutating (destructiveHint=true, readOnlyHint=false), so the description need not restate that. It adds value by detailing what the operation does beyond creation: it sets fields, supports online meetings and recurrence, and the tip clarifies a critical behavioral constraint (resolve emails via list-users). No contradiction with annotations; the description safely adds 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 exceptionally concise: two sentences plus a standalone tip. Purpose and key capabilities are front-loaded, and the tip is clearly separated and highlighted. Every word earns its place, with no fluff or repetition of the schema.
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 without an output schema, the description covers the essential inputs and the key decision of resolving attendees. It does not mention the confirm gate behavior (handled in schema) or side effects like sending invitations, but those are either documented in the schema or implied by the operation. The resource list and the user-email tip together give an agent enough to invoke it correctly in most scenarios.
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 lists the principal resource fields (subject, start/end, time zone, location, body, attendees) and capabilities (online meetings, recurrence), which adds meaning beyond the raw schema. Schema coverage is 75% (likely covering the main event fields and control params), so the description complements but does not fully replace the schema's details. Control parameters (confirm, includeHeaders, excludeResponse) are not mentioned, but those are operational knobs rather than core event 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 a specific verb ('Create (schedule)') and resource ('new calendar event — a meeting or appointment') on the user's calendar. It lists the key attributes (subject, start/end times, time zone, location, body, attendees) and capabilities (online meetings, recurrence), distinguishing it from siblings like update-calendar-event, delete-calendar-event, and get-calendar-event without ambiguity.
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 an explicit, highly actionable tip: do not guess recipient email addresses and instead use the list-users tool. This directly guides agent behavior and prevents a common failure mode. However, it does not explicitly signal when to prefer create-specific-calendar-event over this general variant, so the when-to-use guidance is strong but not exhaustive.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that it updates the task, which implies modification, but does not explicitly warn about destructive implications or mention permissions or side effects. The annotations already indicate destructiveHint and readOnlyHint false, so the description adds minimal behavioral context beyond what is implied by 'update'.
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 well-organized: a clear opening sentence followed by a TIP with examples and prerequisites. No redundancy or unnecessary 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?
The description covers the essential information needed to invoke the tool: what it does, common use cases, and required parameter sourcing. It does not mention the response format or error cases, but given that there is no output schema and the operation is straightforward, it 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 descriptions cover most parameters (83% coverage), and the tool description reinforces the purpose of the body parameter (e.g., status, title, dueDateTime) and clarifies the source of the required IDs. It adds practical guidance on how to use parameters, going slightly 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 ('Update the properties of a todoTask object') and provides concrete examples of updates (mark complete, rename, change due date, etc.). It unambiguously identifies the resource being modified.
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 includes explicit 'Use this to' guidance with specific scenarios, and mentions the required IDs (todoTaskListId and todoTaskId) that must be sourced from list operations. It also shows example usage for common updates, making it highly 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 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses key behaviors: the HTTP 400 error for conflicting parameters, that supplying Message.body replaces the whole draft body (dropping quoted history), that signatures are added only by the Outlook client, and that the draft can be updated later. This is extensive and goes well beyond what annotations already 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 long but well-structured with bullet points and a tip section. It front-loads the primary purpose, then logically breaks down JSON and MIME usage, then adds important caveats. Every sentence earns its place; the length is justified by the complexity of the operation.
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 thoroughly covers error conditions, format choices, and behavioral nuances. It does not mention the return value (e.g., the created draft message object), but no output schema exists, and the description provides enough for an agent to correctly invoke the tool. Minor gap: no explicit guidance on permissions, but that's not typically required for correct invocation.
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 coverage at 80%, the description adds significant meaning to the critical 'body' parameter: it explains the Comment vs. Message.body exclusivity, the MIME format details, and the replacement behavior. It does not explain the 'confirm' parameter, but that's a standard gating parameter already described in the schema. The description compensates well for the uncovered nuances.
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), resource (draft reply), and scope (sender and all recipients) in the first sentence. It also mentions the two output formats (JSON or MIME), which helps distinguish it from related siblings like create-reply-draft or create-forward-draft.
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 strong usage context by explaining the two mutually exclusive ways to specify content (comment vs. message body), the error condition for both, and the MIME base64 requirements. It does not explicitly say 'use this instead of X', but the 'reply-all' framing and the detail on format-specific behavior make the usage context 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?
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 adds meaningful behavioral context beyond the annotations: it discloses that the method saves the message in Sent Items, explains HTTP 400 error conditions for conflicting or missing parameters, and specifies MIME encoding requirements. The destructiveHint annotation is consistent with this side-effect behavior, so there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear JSON and MIME sections, bullet points, and a tip. It is somewhat long, but the added information is operationally important for avoiding HTTP 400 errors and for preserving formatting; the structure makes it 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?
For a complex tool with nested message objects and no output schema, the description covers the main calling formats, key error cases, required recipients, and side effects. It does leave some details to the schema, such as messageId naming, but the description is sufficient for an agent to invoke 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?
With 80% schema description coverage, the schema already documents parameters like messageId and confirm. The description adds critical constraint semantics: the comment/body exclusivity rule, the toRecipients placement rule, the base64 MIME requirement, and the note that toRecipients is required. This goes well beyond what the schema alone conveys.
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 and resource: 'Forward a message' using either JSON or MIME format. It also distinguishes the operation from the create-draft alternative by noting this method saves the message in Sent Items, making it easy to tell apart from sibling tools like create-forward-draft.
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 usage guidance: when to use JSON vs MIME, which parameter combinations are valid versus invalid, and explicitly names the alternative 'create a draft to forward a message, and send it later.' This gives an agent clear conditions for selecting this tool over its siblings.
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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is already covered. The description adds meaningful behavioral context beyond annotations: it expands recurring instances rather than returning only seriesMaster, notes that isOnlineMeeting is not filterable and returns a 400 error, and clarifies that the event resource has no joinWebUrl property. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, with the core purpose front-loaded and a clearly labeled TIP section carrying operational detail. Most sentences earn their place, especially the Teams meeting workflow. However, the opening line's claim about 'some other calendar' conflicts with the subsequent sibling guidance, adding avoidable confusion. Otherwise this would be a 5.
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 complex tool with 15 parameters and no output schema, the description is remarkably complete. It explains what the calendar view returns (occurrences, exceptions, single instances), notes the recurring-instance expansion behavior, specifies required parameters, routes non-default-calendar requests to the correct sibling, and gives actionable guidance for Teams meeting lookup and transcript retrieval. The parameter schema covers the remaining 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 100%, so the baseline is 3. The description adds extra value by emphasizing the required startDateTime/endDateTime format, recommending specific $select fields for Teams meetings, and explaining how to filter by subject with contains(). This goes beyond the schema's per-parameter descriptions and helps an agent compose correct query 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 identifies the action (get occurrences, exceptions, and single instances), the resource (calendar view over a time range), and explicitly distinguishes this from get-specific-calendar-view. However, the first sentence says 'from the user's default calendar, or from some other calendar of the user,' which is internally inconsistent with the later tip telling agents to use get-specific-calendar-view for non-default calendars. This ambiguity prevents a perfect score.
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 explicit when-to-use guidance: it requires startDateTime and endDateTime in ISO 8601, instructs agents to use get-specific-calendar-view for non-default calendars, and provides concrete recipes for Teams meetings and subject search. It also tells agents what not to do (e.g., isOnlineMeeting is not filterable and returns 400). This is exemplary usage 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?
Richly discloses behavior beyond the readOnly/destructive annotations: response contains expanded instances with seriesMasterId and type, isOnlineMeeting/onlineMeetingProvider are not filterable, the event resource has no joinWebUrl property, and fetchAllPages may return enormous payloads. This is exactly the non-obvious behavioral context an agent needs.
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?
Purpose is front-loaded and every block serves a distinct need, but the Teams-meeting guidance is a dense run-on sentence mixing select fields, filter limitations, URL properties, and cross-tool routing; splitting it would improve scannability.
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 and a complex 16-parameter surface, the description supplies important response fields and edge behaviors. It does not fully sketch the response shape, but it covers the high-risk recurrence and Teams cases well.
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 adequate; the description adds value on top by emphasizing that startDateTime/endDateTime are required, explaining non-filterable meeting properties that affect $filter, and recommending fetchAllPages/$select strategies. It does not repeat every schema description but meaningfully supplements the important ones.
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 specific operation (list), resource (occurrences, exceptions, and single instances from one calendar addressed by ID), and time range. The 'not just seriesMaster' note distinguishes it from event-list tools, and the calendar-ID scope separates it from general calendar-view 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?
Clearly frames the intended use: expanded recurring-event instances over a date range for a specific calendar, plus a concrete Teams-meeting workflow and fetchAllPages advice. It does not explicitly name alternative tools or when not to use it, but the context is unambiguous 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?
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?
Annotations indicate readOnlyHint=false (it's a write), destructiveHint=true. The description adds value beyond annotations by explaining conflict behavior options (rename, replace, fail), which is behavioral context the annotations don't provide. It doesn't contradict annotations. Also includes a 'confirm' parameter for destructive gate, which aligns with destructiveness. Slight deduction for not mentioning other side effects, but solid overall.
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 opening sentence, a tip line, and then structured guidance. The most critical information (what body must contain, conflict behavior options) is front-loaded and formatted clearly. No wasted words; each part has 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?
For creating a folder, the description covers essential inputs: driveId, driveItemId, body requirements, conflict behavior. The schema is rich and well-covered. It could mention return values (since no output schema), but for creation tools, this is often obvious. Minor gap: unclear what happens on success (returns created folder item), but given the tool's simplicity, this is quite complete. Not a 5 because it lacks explicit mention of success 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?
Schema description coverage is 83%, high. The description adds critical meaning beyond schema: it explicitly says the body must include 'name' and 'folder' fields, and explains the conflictBehavior mechanism, which is not in the schema. This compensates well for the complexity of the body object. A 4 because it's genuinely helpful but could still deepen details like error handling.
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 exactly what the tool does: 'Create a OneDrive folder' and specifies it creates inside a drive item. It clearly identifies the verb, resource, and context, and distinguishes from siblings like move-rename-onedrive-item and delete-onedrive-file which have different purposes.
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 instructs what the body must include ('name' and 'folder' fields) and how to use '@microsoft.graph.conflictBehavior' to control name conflicts. It implies the context of creation (inside a specified drive item) and is clear about required parameters, preventing incorrect 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?
Annotations say readOnlyHint=false and destructiveHint=true; the description doesn't contradict those, and it goes well beyond them by disclosing the beta status, BETA Graph API volatility, exact account/authentication limits, environmental cloud limitation, and the no-ETag requirement. This substantially reduces the risk of misinvocation.
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 dense but every sentence earns its place: operation, usage context, body format, optimistic caveat, authentication restrictions, and cloud limitations. It is front-loaded with the core action and the practical tip, and doesn't merely repeat the schema.
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 fully explains the operational context, supported message content, mentions, auth/profile constraints, and beta flags, making tool selection and invocation correct without prior knowledge. A brief note about what the create call returns would be nice, but the absence of a return-value shape doesn't block the intended call.
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 about 80%, so the baseline is 3, but the description adds real parameter-level value by giving a compact body grammar: content is 'plain text or sanitized HTML', mentions are optional and contain user-id/position/mentionType. It lets an agent compose the core body without fully parsing the nested schema 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 states the action ('Create a new plannerTaskChatMessage'), the target ('on a plannerTask'), and the context ('task chat' vs the legacy conversationThreadId comment). This makes the tool's purpose unmistakable and distinct from the related planner task message list/delete/update 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 TIP clearly says when to use it: to post per-task updates teammates will see, using the modern task chat rather than the retired classic comments experience. It also gives hard boundary conditions (delegated work/school accounts, no application permissions, no sovereign clouds). It doesn't explicitly name a sibling tool as the alternative, but the legacy path is not a sibling tool here, so 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.
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 exceeds the annotation (destructiveHint: true) by explicitly warning that setting attendees replaces the entire list and that email addresses should be sourced from list-users. This transparently discloses side effects and data sourcing requirements, which are critical for safe and correct usage.
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 a single primary statement and two focused tips. It is well-structured with clear emphasis on the critical warnings, avoiding unnecessary elaboration while conveying essential usage 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 extensive nested schema, the description does not explain every field, but the schema itself provides detailed descriptions. The tips address the most complex and error-prone aspects (attendees and email addresses). It does not mention the return value or response format, but the absence of an output schema makes that less critical. Overall, it is reasonably complete for practical 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?
The schema already provides descriptions for most parameters (80% coverage), but the description adds crucial semantic clarity for the attendees parameter (replacement behavior) and the emailAddress within attendees (use list-users). This supplements the schema, especially for the 'body' and 'eventId' parameters where the tips indirectly clarify 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 that the tool updates properties of an event object, using the verb 'update' and identifying the resource as a calendar event. This distinguishes it from sibling tools that create, delete, or retrieve events, and the added tips reinforce its 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 practical guidance on how to use the tool, specifically warning against guessing email addresses and instructing to use the list-users tool, and explaining the behavior when setting attendees. While it does not explicitly mention when to use this versus other update tools like 'update-specific-calendar-event', the tips give sufficient context for typical usage.
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 tip states that only the role property is writable, which is a key behavioral constraint beyond what the annotations say. The destructiveHint is present, and the description indirectly implies the operation is not purely additive but modifies an existing permission. However, it does not elaborate on potential side effects or irreversibility, so it falls short of a perfect score.
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 line plus a well-structured tip. The tip is broken into clear statements about the role values, writable property, and how to obtain the permission id. It avoids redundancy and presents information efficiently 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?
The description and schema together cover the operation, constraints, and confirmation parameter. A gap is that the tool does not specify which calendar it operates on (e.g., the user's primary calendar) since there is no calendarId parameter. This could lead to ambiguity, but given the tool name 'my-calendar' and the lack of alternatives, it is reasonably inferable. The absence of an output schema is acceptable, as confirmed by the instructions.
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 with descriptive text, so the baseline is 3. The description adds a crucial semantic: 'Only the role property is writable,' which directly clarifies the intended use of the body parameter and the role field. This elevates the score above the baseline, though the description does not dive into other parameter details already covered by 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 a specific verb and resource: 'Update my calendar permission.' The tip clarifies that the operation changes the role for an existing share recipient or delegate, and distinguishes it from create/delete operations. This gives a clear purpose that an agent can use to select the correct tool among similar permission tools.
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 instructs when not to use this tool: 'To change the recipient's email or other properties, delete and recreate via delete-my-calendar-permission + create-my-calendar-permission.' It also tells the agent to get the permission id via list-my-calendar-permissions. This provides clear usage boundaries and directs the agent to alternative actions.
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 doesn't need to restate that. The description adds valuable behavioral context: the API returns an error for built-in lists, and only displayName is writable. It also mentions the confirm gate in the schema, but the description itself doesn't mention the confirm parameter. However, the description's tip about the error case and the writable property goes beyond annotations, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the purpose, and the tip immediately provides the most critical usage detail (rename, body format, writable property, error case, and how to get IDs). Every sentence earns its place; 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?
Given the tool's complexity (5 params, nested body object, no output schema), the description covers the essential points: what to update, the only writable field, the error case, and how to obtain the ID. It doesn't mention the confirm parameter or the includeHeaders/excludeResponse options, but those are self-explanatory from the schema. The description is complete enough for an agent to call this 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 description coverage is 80%, and the description adds key semantics: it clarifies that the body should contain { displayName: 'New name' } and that only displayName is writable. It also clarifies the todoTaskListId parameter by saying to pass it under that name and use the 'id' field from list-todo-task-lists. This adds meaning beyond the schema's generic 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 updates a todoTaskList object, and the tip explicitly says it renames a Microsoft To Do task list. It specifies the writable property (displayName) and distinguishes it from related operations like list-todo-task-lists. The verb 'update' plus the resource 'todoTaskList' 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it says only displayName is writable, and it warns that built-in lists (Flagged emails, default Tasks list) cannot be renamed and will return an error. It also tells the agent to get list ids via list-todo-task-lists, which is a clear pointer to the prerequisite step. This is strong usage 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?
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