m365-mcp

Server Quality Checklist

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

Latest release: v0.2.3
Disambiguation4/5
Tools are mostly distinct due to clear resource grouping (email_, calendar_, etc.). A few convenience wrappers (email_mark_read, email_flag) overlap with email_update but are well-described as simpler alternatives, causing minimal ambiguity.
Naming Consistency4/5
The naming pattern is consistently resource_action (e.g., email_send, calendar_create_event). Minor inconsistency: some resources use plural (emailfolders_) while others singular (email_, contact_), but the pattern is predictable overall.
Tool Count3/5
85 tools is high but justified by the broad scope of Microsoft 365 coverage (email, calendar, contacts, files, search, account, cache). The number is borderline; some consolidation might be possible, but the tools cover distinct subdomains.
Completeness4/5
The tool surface is comprehensive for the covered subdomains (CRUD operations, search, sharing). Minor gaps exist (e.g., folder sharing, recurring events handling), but core workflows are well-supported.
Average 4.4/5 across 85 of 85 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 60 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that rules are executed in sequence order and labels the tool as read-only, but does not disclose any additional behavioral traits like rate limits, authentication requirements, or error handling. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for Args and Returns, uses an emoji for visual appeal, and every sentence adds value. It is appropriately sized and front-loaded with the core purpose. 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?
For a straightforward list tool with one parameter and an output schema, the description covers the core functionality, parameter, and return fields. It lacks context on obtaining the account_id or error scenarios, but given the tool's simplicity and the presence of annotations and output schema, it is mostly 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?
With 0% schema description coverage, the description compensates by specifying 'account_id: Microsoft account ID' in the Args section. This adds basic meaning but lacks details such as format, source, or constraints. The explanation is minimal but sufficient for a simple string parameter.
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 'List all inbox message rules' with a specific verb and resource. It uses emoji and mentions read-only nature, clearly indicating it's a list operation. However, it does not explicitly differentiate from sibling tools like emailrules_get or emailrules_create, though the action 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?
The description includes 'safe for unsupervised use' but provides no guidance on when to use this tool versus alternatives such as emailrules_get for a specific rule or emailrules_create for adding rules. No exclusions or context for appropriate 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?
Beyond the annotations (destructiveHint, readOnlyHint), the description adds critical context: permanent deletion, requirement for user confirmation, and the need to set confirm=True. This is valuable information for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a short warning and bullet-style argument list. Every sentence adds value, and the structure is easy to parse.
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 action, warning, and parameter meanings. However, it omits details about the output schema (only says 'Status confirmation') and does not mention required parameters explicitly.
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 0% schema description coverage, the description compensates by listing the three parameters and their purposes. However, it lacks details on formats, constraints, or how to obtain values.
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 deletes a contact permanently. It uses a specific verb and resource, distinguishing it from other contact tools like create or update.
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 only explains the deletion behavior but does not help an agent decide between similar 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?
While annotations provide destructiveHint=true, the description contradicts the schema by stating confirmation is always required, yet the 'confirm' parameter is optional with default false. This misrepresentation lowers 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 sentences, no fluff, with an effective warning. Every word serves a 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 core behavior but lacks details on prerequisites, error conditions, or the output. The contradiction with the confirm parameter also reduces completeness.
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 0% and the description only implicitly references the 'confirm' parameter. It does not explain 'file_id' or 'account_id', leaving their meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 ('OneDrive file or folder'), distinguishing it from sibling tools like file_copy, file_move, etc.
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 warns about permanence and user confirmation, but does not explicitly guide when to use this tool versus the sibling 'folder_delete' tool, which could cause confusion.
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 mentions 'requires user confirmation recommended' and raises ValueError for invalid inputs. Annotations are minimal, so the description compensates well.
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 clear sections (Args, Returns, Raises). It is front-loaded with purpose. The emoji is minor but does not hinder clarity.
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, all parameters, return value, and error conditions. It mentions confirmation need. Missing details on permissions or idempotency, but sufficient for basic 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 docstring briefly explains each parameter's purpose (folder_id, new_name, account_id). Since schema description coverage is 0%, this provides basic semantics but lacks constraints or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 renames an OneDrive folder. It distinguishes from sibling tools like folder_move or folder_delete by specifying the action 'rename'.
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 like folder_move. It does not mention prerequisites or scenarios where other tools are preferred.
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, destructiveHint, idempotentHint, and openWorldHint as true. The description reinforces that it's read-only and safe, and adds value by detailing the return fields (e.g., is_warming, progress_percent) and providing an example. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, a bulleted list of return fields, and an example. It is not overly long, though the emoji and detailed list could be slightly trimmed. The information is 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?
For a tool with no parameters and existing annotations, the description fully covers the behavior and return format. It lists all expected fields in the response, provides context on when each field is populated (e.g., started_at when active), and includes a usage example. No gaps remain.
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, and schema description coverage is 100% (trivially). The description adds meaning beyond the schema by documenting the full return dictionary with field descriptions and an example, which helps the agent understand the output without needing an explicit output 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 'Get cache warming status and progress', specifying the verb (get) and resource (cache warming status). It includes a read-only badge, but does not differentiate from sibling tools like cache_get_stats or cache_task_get_status, which could also provide related status info.
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 safe unsupervised use ('read-only, safe for unsupervised use') which suggests it can be called freely, but it does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or comparisons to siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds 'requires user confirmation recommended' and clarifies it creates data, providing some behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise, using an emoji for visual cue and front-loading purpose. The Args section adds value but could be slightly more streamlined.
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 key creation parameters and includes a Returns line. Given the presence of an output schema, it is reasonably complete, though it omits error conditions and permission requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by listing each parameter with clear explanations, including required status and acceptable types (e.g., phone_numbers as dict with specific keys).
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 contact' and details the components (name, email, phone). It distinguishes itself from sibling tools like contact_update and contact_delete.
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 the tool (to create a contact) but offers no explicit guidance on when not to use it or mention of alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it notes potential slowness for large folders, recommends confirmation, and specifies a ValueError for invalid folder_id. Annotations already indicate idempotent and non-destructive, and the description aligns.
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 short elaboration, then structured Args/Returns/Raises sections. 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?
The description covers behavior, parameters, return type, and errors. Given the tool's simplicity and the presence of an output schema (though not detailed here), it is fairly complete. Minor omission: no mention of whether the operation is all-or-nothing.
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 0% description coverage, but the description's Args section provides meaningful explanations for both parameters: folder_id as the folder to mark and account_id as the Microsoft account. This adds value beyond the raw 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 marks all messages in a folder as read, but does not explicitly differentiate from the sibling email_mark_read tool which works on individual emails. The verb 'mark all' is specific, but lack of direct comparison 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the operation may take time and recommends user confirmation, but provides no direct guidance on when to use this tool versus alternatives like email_mark_read. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag it as non-read-only, non-destructive, non-idempotent, and open-world. The description adds valuable context: the operation is asynchronous and may take time for large files, and it requires user confirmation. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose sentence, then Args, Returns, Raises sections. The emoji and 'recommended' comment are slightly informal but do not add unnecessary length. Every sentence contributes value, though some details could be condensed.
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 presence of an output schema and sibling tools, the description covers purpose, async behavior, parameters, returns, and errors. Missing details include default naming behavior when new_name is omitted and permission requirements, but overall it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It provides brief explanations for each parameter (e.g., 'file_id: The file ID to copy'), but lacks details on formats, sources, or constraints (e.g., where to find account_id, naming rules for new_name). This is minimal but sufficient for basic use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Copy a file within OneDrive', specifying the verb 'copy' and resource 'file'. It distinguishes from sibling tools like file_move (which moves instead of copies) and file_create (which creates a new empty file).
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 via 'copy a file' and notes it's asynchronous, but does not explicitly state when to use this tool versus alternatives like file_move or file_rename. It mentions 'requires user confirmation recommended' but lacks 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?
Annotations already indicate mutation (readOnlyHint=false) and non-destructive nature. The description adds a recommendation for user confirmation but does not detail side effects, permission requirements, or behavior on conflict. 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 and front-loaded with the purpose. The use of an emoji and docstring format is clear, though some lines (e.g., returns/raises) are standard and 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?
Given the presence of an output schema, the description sufficiently covers return values and errors. However, it lacks details on edge cases like name conflicts or whether the operation is reversible, which would improve completeness for a mutation 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?
The description provides meaningful descriptions for all three parameters (file_id, new_name, account_id) beyond the raw schema types and required flags, and also documents return and error types. With 0% schema description coverage, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 renames a file ("Updates the name of an existing OneDrive file") with a specific verb and resource. It distinguishes from sibling tools like file_move and folder_rename by focusing on renaming.
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?
While the description mentions "requires user confirmation recommended," it does not explicitly state when to use this tool versus alternatives like file_move or file_update. No exclusions or context for avoiding misuse are 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 declare readOnlyHint=true and destructiveHint=false. The description adds context by repeating 'read-only, safe for unsupervised use,' and details return type (free/busy information) and possible errors (ValidationError, ValueError). 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, well-structured, and front-loaded with the main purpose. Each section (args, returns, raises) is clearly separated, 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 the tool has 4 parameters and an output schema, the description covers purpose, parameters, return format, and errors. The presence of an output schema means the description does not need to detail the return structure, making it 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?
Despite 0% schema description coverage, the description lists each parameter with a brief explanation (e.g., 'start: Start time in ISO format'). This adds meaning that the schema alone does not provide, compensating for the lack of schema 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 checks calendar availability for scheduling and returns free/busy information. It is distinct from siblings like calendar_create_event, but could differentiate from calendar_get_free_busy, which also deals with free/busy data.
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 says 'Useful for finding meeting times,' implying usage context. However, it does not specify when not to use this tool or mention alternatives like calendar_get_free_busy, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and non-destructive. The description adds that it requires user confirmation (recommended), returns a status confirmation with new email ID, and raises ValueError for invalid email ID or missing archive folder. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections for Args, Returns, and Raises. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool is simple, the description covers the essential behavior and return value. Sibling tools are many, but the differentiation from email_move is clear.
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 description coverage is 0%, and the description only adds minimal one-line explanations for each parameter (email_id and account_id). More detail would help, but the parameters are simple.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 (archive an email) and resource (email), and explicitly distinguishes from sibling tool email_move by calling it a convenience wrapper that targets the archive 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 explains it is a quick action for archiving, recommends user confirmation, and notes it's a wrapper around email_move, implying it should be used when archiving vs moving to other folders. However, 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?
The description discloses safety validation via ensure_safe_path and that existing files are never overwritten. This adds value beyond annotations, which already indicate idempotency and non-destructiveness. Missing error handling details, but sufficient for the tool's simplicity.
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: one sentence purpose, then clear Args and Returns sections. No extraneous information; every sentence adds necessary 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?
Given the presence of an output schema, the description sufficiently covers inputs and key behavior. It lacks error handling descriptions, but for a tool with 4 simple parameters, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description elaborates on each parameter, including validation for save_path and the role of email_id and attachment_id. This compensates well, though format constraints (e.g., path requirements) are not specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads an attachment to a validated local path, using specific verbs and resources. It distinguishes itself from sibling tools like 'email_get' which retrieves the message itself, not the attachment.
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 such as 'email_get' or other attachment-related tools. The agent must infer usage from 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds 'read-only, safe for unsupervised use' and mentions returned properties but does not disclose any other behavioral traits like rate limits or auth requirements beyond the account_id parameter.
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 a main sentence, then Args and Returns sections. It is fairly concise with no fluff, though the docstring format adds a bit of formality. Could be slightly shorter but is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately explains return values (childCount, webUrl, parent info). It mentions folder_id precedence but lacks discussion of error cases or resolution behavior for path. Overall, it covers the essential context for a simple get tool.
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?
With 0% schema description coverage, the description provides detailed explanations for all three parameters: account_id as Microsoft account ID, folder_id with precedence note, and path with an example. This fully compensates for the missing schema descriptions and adds clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Get metadata for a specific OneDrive folder' with a verb and resource. It distinguishes from siblings like folder_get_tree (which likely returns tree structure) and folder_list (which lists folders). The read-only and safe qualifier further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving metadata but does not explicitly mention when not to use it or suggest alternatives like folder_list for listing contents. The 'safe for unsupervised use' hints at appropriate contexts, but lacks explicit guidance.
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 mentions deletion of cache entries, implying a destructive action, yet the destructiveHint annotation is false. This is a contradiction. Additionally, while it discloses the return values and pattern matching behavior, it does not discuss performance implications or authentication requirements beyond the optional account_id parameter. The annotation contradiction reduces 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 well-structured with sections (Args, Returns, Examples) and front-loaded with a clear purpose. It is slightly verbose but every sentence adds value. The emoji provides instant recognition. Could be more concise, but overall efficient.
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 output schema exists and is referenced in the description, the description covers all aspects: what the tool does, parameters, return values, and examples. The tool has moderate complexity and the description is complete for effective use.
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 0% schema description coverage, the description provides extensive details for each parameter: pattern supports wildcards with examples, account_id scoping, and reason default/audit logging. This fully compensates for the lacking schema descriptions and adds significant 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 invalidates cache entries matching a pattern. It uses specific verbs ('Invalidate', 'Delete') and specifies the resource ('cache entries'). It distinguishes from sibling cache tools like cache_get_stats and cache_warming_status by explicitly being the invalidation tool.
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 it: for forcing fresh data retrieval or clearing stale cache entries. It includes examples for common use cases. Although it doesn't explicitly state when not to use it, the context of sibling tools and the note about user confirmation provide sufficient guidance. Lacks explicit exclusion of 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 provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds 'safe for unsupervised use' and specifies return content (recurrence, meeting details), which is useful but 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?
Very concise with clear structure: emoji header, one-sentence purpose, then parameter list. No superfluous information; 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?
Covers purpose, parameters, and return content. Output schema exists so return details are not needed. Minor lack of cache behavior nuances, but adequate for a read-only tool.
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 explicitly lists and explains all four parameters with roles and defaults. Since the input schema lacks descriptions, the description fully compensates (schema coverage 0%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Get full event details (read-only)' and mentions recurrence and online meeting details. It distinguishes from sibling tools like calendar_list_events and calendar_update_event by emphasizing completeness and read-only nature.
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 'safe for unsupervised use' but does not explicitly state when to use this tool versus alternatives like calendar_list_events or calendar_get_free_busy. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation and side effects (openWorldHint=true). The description adds 'requires user confirmation recommended' but doesn't detail the process or potential side effects adequately.
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 summary, usage note, and parameter list. It's slightly lengthy but not wasteful. The 'requires user confirmation recommended' could be phrased 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 description covers basic usage, but given openWorldHint=true and an output schema exists, more details about what happens after proposing (e.g., organizer receives request) would improve completeness.
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 0% schema coverage, the description includes detailed Args with examples (ISO date formats) and explains each parameter's purpose, fully compensating for the schema's lack of 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 proposes a new meeting time, specifying it's for attendees only, which distinguishes it from sibling tools like calendar_update_event for organizers.
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?
It explicitly says when to use: when invited but the time doesn't work, and notes the limitation of only working for attendees. It doesn't name alternatives but provides clear 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 indicate not read-only, destructive, or idempotent. Description adds the behavioral trait of requiring user confirmation and lists possible ValueError, providing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with Args, Returns, Raises sections, and is concise overall. The emoji and recommendation add value without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given presence of output schema, description still provides return and error details. Covers creation scenarios and error conditions, making it complete for a creation 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 has 0% description coverage, so description compensates by explaining each parameter's meaning and default behavior for parent_folder_id. Also describes return 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 verb 'create' and resource 'mail folder', with additional scope (root level or child of existing folder). This distinguishes it from siblings like rename, delete, etc.
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 mentions 'requires user confirmation recommended' and explains parent_folder_id for root vs child, but does not explicitly state when to use this tool vs alternatives 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behaviors: requires user confirmation, sends immediately, cannot be undone, body is whitespace-stripped and validated. This adds value beyond annotations, though auth requirements are omitted.
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 a warning and key constraints. Each sentence serves a purpose, but the args list could be integrated more naturally.
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 presence of an output schema, the description adequately covers purpose, parameters, behavior, and error conditions. It mentions return status and possible ValidationError, which is sufficient for a straightforward 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?
With 0% schema coverage, the description explicitly lists and explains each parameter (account_id as Microsoft account ID, email_id as email ID, body as plain text, confirm must be True). The explanations are clear and sufficient, though more detail on formats could improve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 this tool replies to an email, with specific mention of sending to the original sender. It distinguishes from sibling tools like email_reply_all and email_forward by specifying 'original sender'.
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 (to reply to original sender) but does not explicitly contrast with alternatives like email_reply_all or email_forward. No prerequisites or context for when to avoid are 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 indicate non-destructive and idempotent behavior. The description adds the important behavioral note that user confirmation is recommended, which goes beyond annotation hints. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and well-structured, using a bullet-like list for parameters and front-loading key information with an icon. It avoids unnecessary elaboration.
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 an update tool with 8 parameters and no nested objects, the description covers the essential purpose, allowed fields, and return value. The presence of an output schema (not shown) reduces the need to describe return format further.
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 0% schema description coverage, the description adds basic semantics for each parameter (e.g., 'New name for the rule (optional)'). However, it lacks details for complex parameters like conditions, actions, and exceptions, which remain opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 (an existing message rule). It lists the modifiable properties and distinguishes from sibling tools like emailrules_create or emailrules_delete. The verb+resource combination 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 notes that user confirmation is recommended and that at least one field must be provided. While it doesn't explicitly state when not to use this tool versus alternatives (e.g., emailrules_create for new rules), the context from sibling names makes the distinction 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?
Adds context beyond annotations: requires user confirmation, path validation to prevent traversal, returns metadata. Annotations are neutral.
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?
Concise, uses structured Args/Returns, front-loaded with emoji. Could be slightly more succinct.
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 all 3 parameters, mentions output metadata and security validation. Adequate for a file upload tool with many siblings.
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 0% schema coverage, description explains each parameter: onedrive_path must start with '/', local_file_path is absolute path with validation, account_id is identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Upload' and resource 'local file to OneDrive', distinguishing from siblings like file_copy, file_delete.
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?
Gives specific action but no when-to-use or when-not-to-use guidance vs. alternatives among many file-related 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 indicate non-read-only and non-destructive. The description adds behavioral traits: creates at root or child, requires user confirmation, raises ValueError for invalid inputs. 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 concise with clear sections (Args, Returns, Raises) and no redundant information. The emoji and user confirmation note are front-loaded. Could remove the 'Args:' prefix since schema already defines, but it's still 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 moderate complexity (3 params, output schema exists), the description covers creation behavior, parameter semantics, return value, and error cases. Missing details like behavior on duplicate names or permissions, but overall sufficient 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?
Input schema has 0% parameter descriptions, so the description compensates by explaining the purpose and constraints of each parameter (name, account_id, parent_folder_id with default None). Could include validation rules or formatting, but still adds significant 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 verb (create), resource (OneDrive folder), and scope (root or child of existing folder). It distinguishes itself from sibling tools like file_create and emailfolders_create by specifying it's for OneDrive 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?
The description mentions 'requires user confirmation recommended' but does not provide explicit guidance on when to use this tool versus alternatives (e.g., folder_move, folder_rename) or when not to use it. No reference to 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 provide basic mutation flags (readOnlyHint=false, destructiveHint=false). The description adds valuable behavioral details: attendees receive invitations, addresses are validated/deduplicated/limited to 500, and ValidationError raised for invalid inputs.
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 summary, parameter details, returns, and raises sections. It is front-loaded with the purpose. Minor redundancy (e.g., 'optional' repeated) but overall efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (8 parameters, 4 required), the description covers parameter syntax, error conditions, and side effects (attendees invited). The return type is vaguely mentioned but an output schema is noted to exist, so this is acceptable.
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 description coverage is 0%, so the description carries the full burden. The 'Args' section explains each parameter's meaning (e.g., account_id is Microsoft account ID, start/end in ISO format), adding critical semantic value beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a calendar event' with specific verb and resource. It differentiates from sibling tools like calendar_update_event and calendar_delete_event by its focus 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates this tool is for creating events, but lacks explicit guidance on when not to use it or alternative tools. The 'requires user confirmation' note is more about safety than 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=false and destructiveHint=false. The description adds the behavioral trait 'requires user confirmation recommended,' which is beyond what annotations provide. It also clarifies the resource type ('contact folder/list'). No contradiction with annotations. However, it omits details on permissions or rate 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 and well-structured: it opens with a clear purpose, then provides usage context, parameter descriptions, return information, and error details. Each sentence adds value, and the formatting (Args, Returns, Raises) makes it 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's simplicity (2 params, output schema exists), the description is fairly complete. It explains the function, parameters, return object, and error case. It does not explicitly mention prerequisites like authentication, but since sibling tools include account_authenticate, this is likely understood. A small gap is the lack of uniqueness constraints on list_name.
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 0% schema description coverage, the description fills the gap by providing semantic meaning for both parameters: 'account_id: Microsoft account ID' and 'list_name: Name for the contact list/folder.' This adds necessary context beyond the schema's bare property definitions, though more detail (e.g., allowed formats) could be 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 clearly states the tool creates a contact list (folder) for organizing contacts. It uses a specific verb ('Creates') and resource ('contact list'), and the examples of use cases (distribution lists, project teams) distinguish it from sibling tools like contact_create (which creates individual contacts) and contact_add_to_list (which adds to existing lists).
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 mentions it is 'useful for creating distribution lists, project teams, or other groupings,' giving context for when to use it. However, it does not explicitly state when not to use it or compare it with alternatives like contact_add_to_list for adding contacts to existing lists. The guidance is implied but not sharply differentiated.
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 a non-read-only, non-destructive write operation. The description adds context: 'requires user confirmation recommended', drafts can be edited, and supports attachments. This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose sentence, an Args list, and a Returns section. It is concise, though the emoji is minor clutter. Front-loaded with key 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?
The description covers purpose, parameters, and basic return. An output schema exists for detailed return structure. Missing mentions of authentication or prerequisites, but given sibling tools and annotations, it is fairly complete.
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 0%, so the description must explain parameters. It provides an Args section with brief descriptions for all six parameters (account_id, to, subject, body, cc, attachments), adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Creates a draft email message that can be edited later before sending.' It uses the verb 'create' and the resource 'email draft', distinguishing it from siblings like email_send, email_reply, and email_get.
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: creating drafts for later sending, but lacks explicit guidance on when to use this tool versus alternatives like email_send or email_update. It mentions 'requires user confirmation recommended' but does not provide 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral traits beyond annotations: it warns that user confirmation is recommended and lists error conditions (ValueError for invalid folder_id or empty new_display_name). Annotations indicate idempotentHint=true and destructiveHint=false but lack detail on confirmation or error handling.
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 (4 sentences) and well-structured with sections for Args, Returns, and Raises. The emoji front-loads the action, and every sentence provides essential information 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 rename tool with 3 parameters and existing output schema, the description covers purpose, parameters, return ('Updated folder object with new displayName'), and error cases. It lacks details about authentication requirements beyond the account_id parameter, but overall it is complete enough for an agent to understand and invoke it 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 schema description coverage at 0%, the description compensates by explicitly defining each parameter in the Args section: 'folder_id: The folder ID to rename', 'new_display_name: New name for the folder', 'account_id: Microsoft account ID'. This adds meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename a mail folder') and the resource ('mail folder'), with a specific verb 'rename' that distinguishes it from sibling tools like emailfolders_create, delete, or move. The title 'Rename Email Folder' reinforces this.
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 explicitly state when to use this tool versus alternatives (e.g., emailfolders_move, emailfolders_update). The context of 'renaming' is implied but no comparison or exclusion criteria are provided, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm readOnlyHint=false (modification) and destructiveHint=false. The description adds the behavioral note about user confirmation and raises ValueError for invalid IDs, enhancing 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 and well-structured with an emoji, brief intro, and clearly separated Args, Returns, and Raises sections. 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?
For a simple move operation with output schema and annotations, the description covers purpose, parameters, return type, and errors. Lacks details on potential conflicts or permission needs, but openWorldHint partially addresses side effects.
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 0%, but the description provides clear explanations for each parameter under Args (folder_id, destination_folder_id, account_id), adding meaning beyond the raw type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 an OneDrive folder to a different parent, using a specific verb and resource. It distinguishes from sibling tools like folder_rename and file_move by focusing on folder hierarchy change.
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 mentions 'requires user confirmation recommended' but does not explicitly state when to use this tool versus alternatives like file_move or when not to use it. No guidance on prerequisites or conditions.
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=false. The description adds a user confirmation recommendation and explicit error handling (ValidationError), providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with sections for usage, args, returns, and raises, though the emoji and redundant phrasing 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?
Given the tool's simplicity (create a calendar), the description covers purpose, parameters, return value, and error conditions. The presence of an output schema reduces the need to detail return structure further.
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 0% description coverage, but the description explicitly explains both parameters (account_id and name) in the Args section, adding meaning beyond the bare 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 'creates' and resource 'calendar in the user's mailbox.' Among siblings like calendar_delete_calendar and calendar_list_calendars, it is distinct 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 use cases (work, personal, project-specific calendars) but does not explicitly state when not to use or mention alternatives like updating an existing calendar.
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 recommends user confirmation, states the action sends a response to the organizer, mentions case-insensitivity and alias for 'tentative', and notes potential ValidationError. Annotations indicate idempotentHint=true and readOnlyHint=false, which are consistent with the described behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (warning, important note, valid responses, args, returns, raises). It is front-loaded with a warning but includes some redundancy (e.g., default value mentioned in description and schema). Overall, 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?
The description covers the tool's purpose, parameter semantics, expected output (status confirmation), and possible errors. With a relatively simple tool and an output schema available (context indicates exists), the description is sufficiently complete for agent 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?
The input schema has 0% description coverage according to context signals, meaning no parameter descriptions in the schema. The tool description compensates by providing an Args section that explains each parameter, including valid values for 'response' and its case-insensitivity. This adds significant 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 action 'Respond to a calendar event invitation' and identifies the resource as a calendar event invitation. It distinguishes from sibling tools like calendar_create_event or calendar_delete_event by specifying the response 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 clear usage context by listing valid response values ('accept', 'decline', 'tentativelyAccept') and notes that it sends a response to the organizer. However, it does not explicitly state when not to use this tool or suggest alternatives for other operations.
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, destructiveHint, idempotentHint, and openWorldHint, so the tool is safe. The description adds context about error conditions (ValidationError, ValueError) and the format limitation (only 'vcard' supported), enhancing 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, structured with a summary line, Args, Returns, and Raises sections. It front-loads key information (emoji, read-only tag) and contains no 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?
Given that the tool is read-only with comprehensive annotations and an output schema (not shown), the description covers input parameters, error behavior, and output intent. It is complete for its purpose.
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 0%, but the description includes an Args section that explains all three parameters: account_id, contact_id, and format (with supported value). This compensates for the missing schema descriptions and meets the baseline of 4 for low 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 'Export a contact in vCard format (read-only, safe for unsupervised use)', which is a specific verb-resource combination. It distinguishes from sibling tools like contact_get, contact_list, and contact_update by focusing on export.
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 exporting contacts to vCard and mentions read-only safety, but does not explicitly contrast with sibling tools or provide when-not-to-use guidance. No alternatives are named.
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, destructiveHint, idempotentHint, openWorldHint. The description adds valuable behavioral context: caching details (30 min fresh, 4 hours stale, use_cache, force_refresh) and output fields _cache_status and _cached_at. This goes beyond what annotations provide, though it does not mention error handling or rate 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 well-structured with a header, caching paragraph, parameter list, and return format. It uses emojis for visual cues 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context signal) and rich annotations, the description covers all essential aspects: purpose, caching behavior, parameter semantics, and return fields. It is complete for a read-only get 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 0% (no descriptions in JSON schema). The description explains all four parameters with meaningful labels: contact_id, account_id, use_cache, force_refresh, including defaults and behaviors like 'bypass cache'. This compensates well for the missing schema descriptions, though format details (e.g., contact_id format) are absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Get contact details (read-only, safe for unsupervised use)' and 'Returns complete contact information including all fields.' This is a specific verb-resource pair that distinguishes it from sibling tools like contact_list, contact_create, etc.
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 retrieving a single contact's details, with caching options. However, it does not explicitly state when to use this vs alternatives like contact_list or search_contacts, nor does it provide when-not or exclusion criteria.
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, destructiveHint, idempotentHint, and openWorldHint. The description adds behavioral context like requiring user confirmation and listing allowed update keys, but does not detail side effects or partial update 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 well-structured with a summary, field list, parameter explanations, and return value, all in a concise format 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?
The description covers allowed fields and return type, but lacks clarification on whether the update is partial or full replacement. Given the output schema exists, this is a minor gap.
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 description coverage is 0%, but the description lists allowed update keys and explains each parameter (contact_id, updates, account_id) with clear descriptions, adding significant 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 updates contact information, lists specific modifiable fields, and distinguishes from sibling tools like contact_create, contact_delete, and contact_get.
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 note about user confirmation but lacks explicit guidance on when to use this tool versus alternatives, and does not specify 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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds 'read-only, safe for unsupervised use' and specifics about returned fields (counts, hierarchy). This adds some value beyond annotations but not extensive 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 a clear structure: purpose, safety note, return summary, and args. No unnecessary words, and front-loaded with key 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?
Given the tool's simplicity (2 parameters, output schema exists), the description fully explains the purpose, parameters, and return fields. It is complete for the agent to understand how to use 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?
Schema coverage is 0%, but the description includes a brief explanation for both parameters (folder_id and account_id), giving basic context that the schema lacks. This compensates for the missing 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 it retrieves detailed info about a specific folder, with a specific verb and resource. It distinguishes itself from related tools like emailfolders_list and emailfolders_get_tree by focusing on a single folder's metadata.
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: 'read-only, safe for unsupervised use' and mentions the returned data type. It does not explicitly say when not to use or name alternatives, but the context implies its use for getting a single folder's 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?
The description adds value beyond annotations by noting user confirmation is recommended and clarifying the move operation's effect. Annotations already indicate non-destructive and idempotent behavior, but the description doesn't contradict 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 concise, front-loaded with a summary, and uses a structured Args list. Every sentence adds value without 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?
The description covers purpose, parameters, return value, and a safety note. It lacks details on permissions, error handling beyond ValueError, or integration with sibling tools like emailfolders_get_tree, but is adequate given the 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?
With 0% schema description coverage, the description provides clear, helpful explanations for each parameter (folder_id, destination_folder_id, account_id), significantly adding meaning beyond the schema's type and required attributes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 ('Move a mail folder to a different parent') and the resource ('mail folder'), distinguishing it from sibling tools like emailfolders_rename or emailfolders_delete.
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 mentions user confirmation recommendation but provides no explicit guidance on when to use this tool versus alternatives (e.g., emailfolders_delete, emailfolders_empty), nor 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 provide readOnlyHint=false and destructiveHint=false, which the description complements by indicating the tool creates rules (write operation) and recommending user confirmation. It also explains execution order, adding behavioral context beyond annotations. However, it doesn't detail failure modes 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, behavior, examples, arguments, and returns. It is front-loaded with the key purpose. While comprehensive, it is slightly longer than necessary; the examples could be more concise.
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 (7 parameters, nested objects, no output schema in structured input), the description is thorough. It explains conditions/actions with examples, covers all parameters, and describes the return value. It is complete enough for an agent to understand and use the tool.
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 the input schema lacks parameter descriptions (coverage 0%), the description compensates with a detailed 'Args' list explaining each parameter, including default values and examples for complex objects like conditions and actions. This adds significant 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 explicitly states the tool creates a new inbox message rule to automatically process emails, using a specific verb and resource. It clearly distinguishes itself from sibling tools like emailrules_update or emailrules_list 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that user confirmation is recommended and explains priority order, but does not specify when to avoid using this tool or provide explicit comparisons to siblings like emailrules_update. It lacks guidance on prerequisites or scenarios where the 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?
The description adds nuance beyond annotations, noting that user confirmation is recommended and specifying that the tool returns an updated rule with a new sequence number. This complements the annotations which indicate a non-destructive modification.
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 well-structured, using a brief heading, callout, and separate Args/Returns sections. No unnecessary words, though it could be slightly more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameter semantics, and return value adequately. Given that an output schema exists, the return value description is sufficient. However, it lacks information on error handling, prerequisites, or rate limits, which is acceptable for this 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?
Given the 0% schema description coverage, the description compensates by providing brief but clear descriptions for both parameters: rule_id is the message rule ID to move, account_id is the Microsoft account ID. This gives agents basic understanding of 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?
The description clearly states that the tool moves a message rule to the bottom of execution order, using the verb 'move' and resource 'email rule'. This distinguishes it from sibling tools like move_down, move_top, and move_up, which move rules in different ways.
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 that rules execute in sequence order and that moving to bottom means the rule runs after all others. It provides clear context for when to use the tool, though it does not explicitly mention when not to use it or compare with 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 (readOnlyHint=false, destructiveHint=false) indicate mutation; the description adds that it moves the rule down one position, cannot be moved if at the bottom, and requires user confirmation. No contradictions, and adds useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using an emoji-title, a short paragraph, and clearly labelled args and returns. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move operation, the description covers purpose, constraints, required parameters, and return type. With an output schema present, the return description ('Updated rule with new sequence number') 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?
With 0% schema description coverage, the description provides brief but clear parameter meanings ('The message rule ID to move' and 'Microsoft account ID'). This is adequate but could include format or source details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: 'Move a message rule down one position in execution order' and 'Decreases the rule's priority.' It specifies the resource (message rule) and effect, and distinguishes from siblings like emailrules_move_up and emailrules_move_bottom.
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 mentions a constraint ('Rules at the bottom cannot be moved down further') and notes that user confirmation is recommended, but lacks explicit guidance on when to use this vs. alternatives like emailrules_move_up or emailrules_move_bottom. Only implied 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?
Annotations are minimal, but the description adds behavioral context: requiring user confirmation, incrementally moving up, and the inability to move the top rule. This 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 a clear title, short paragraph, and structured Args/Returns sections. No 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?
Given the simple tool (2 parameters, no nested objects) and the presence of output schema, the description covers the purpose, constraints, and return value 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 0%, but the description includes a one-line explanation for each parameter ('The message rule ID to move', 'Microsoft account ID'), adding some meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 ('Move a message rule up one position in execution order') and the resource ('message rule'), distinguishing it from sibling tools like emailrules_move_down and emailrules_move_top.
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 (to increase priority) and a constraint ('rules at the top cannot be moved up'), but does not explicitly compare to alternatives like move_down or move_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 readOnlyHint=false and idempotentHint=false. The description adds that it initiates device flow, requires user confirmation, and is not idempotent, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and uses structured steps. It is slightly lengthy but well-organized and clear.
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 zero parameters and the presence of an output schema, the description fully covers the tool's function and process, linking to the completion step.
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, so default to baseline 4. The description adds no parameter info, which is unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 authenticates a Microsoft account using device flow and returns instructions. It distinguishes itself from the sibling tool account_complete_auth, which completes the process.
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 outlines the steps for the user and mentions that account_complete_auth should be used afterward, providing clear context on when to use this tool. However, it does not explicitly state when not to use it or list 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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds value by detailing the exact statistics returned, such as hit rates and compression ratios, and reassures 'safe for unsupervised use'. 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 well-structured with a header, safety note, bullet list of return fields, and an example. It is somewhat lengthy but every sentence adds value. Front-loading of key info is good.
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 zero parameters and a likely rich output schema, the description thoroughly explains the return fields and provides an example. It is fully self-contained for an agent to understand the tool's purpose and output.
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, so the description naturally has minimal param info. The schema coverage is 100% (none). The description provides an example usage, adding practical 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 cache statistics and performance metrics, distinguishing it from sibling tools like 'cache_invalidate' and 'cache_warming_status'. It emphasizes 'read-only, safe for unsupervised use', which is a specific verb+resource combo.
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 marks the tool as safe and read-only, implying it's appropriate for any monitoring context. While it does not provide explicit exclusions or alternatives, 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, idempotentHint, etc. The description adds value by detailing the return structure (fields like status, progress, error) and the error case (ValueError for missing task_id), 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and uses clear sections (Args, Returns, Raises). It is slightly verbose due to the detailed Returns list, but every sentence adds value. Could be slightly more concise without losing 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?
Given the simple tool (one required parameter) and the existence of an output schema, the description covers purpose, parameter, return structure, and error handling thoroughly. No gaps are apparent.
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 0%, so the description must fully explain parameters. It describes task_id as 'the unique identifier for the cache task', adding meaning beyond the schema's simple type definition. The single parameter is well-described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specifies the verb 'Get status' and the resource 'background cache task'. It distinguishes from sibling tools like cache_task_list (which lists all tasks) and cache_get_stats (which likely returns aggregate stats) by focusing on a single task's status.
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 notes the tool is 'read-only, safe for unsupervised use' and implies it should be used to check status of a specific background cache task. However, it does not explicitly state when to use alternatives like cache_task_list 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: the contact is copied (not moved), and it requires user confirmation. Annotations only indicate readOnlyHint=false and openWorldHint=true, so the description adds significant 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?
The description is concise and well-structured, with a purpose statement, behavior details, parameter list, return value, and error information. No 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?
Given the tool's simplicity, the description is complete: it explains the operation, all parameters, return type, and possible error. Even with an existing output schema, it provides necessary context.
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?
With 0% schema description coverage, the description fully explains each parameter (account_id, contact_id, list_id) with clear meanings. This compensates entirely for the lack of 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 action 'Add a contact to a contact list' and explains that the contact is copied, distinguishing it from creating a new contact or list. It uses a specific verb-resource pair.
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 adding existing contacts to lists but does not explicitly state when to use this tool vs alternatives like contact_update or search_contacts. No exclusions or context for when not to use it are 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 declare readOnlyHint, destructiveHint, and idempotentHint. The description adds caching behavior (20 min fresh, 2 hours stale) and the force_refresh parameter, which provides additional 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 well-structured with an emoji, clear sections for output, caching, arguments, and returns. Every sentence is informative and necessary, with no wasted 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?
Given the tool's complexity (4 parameters, many siblings, output schema exists), the description covers safety, caching, parameter details, and return fields. It is sufficiently complete for effective use.
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 description coverage is 0%, so the description fully compensates by explaining each parameter in detail: account_id, limit (with range), use_cache, and force_refresh. It clarifies defaults and caching logic, adding significant 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's purpose: '📖 List contacts (read-only, safe for unsupervised use)'. It specifies what it returns ('names, email addresses, and phone numbers'), distinguishing it from siblings like search_contacts and contact_get.
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?
While the description indicates the tool is read-only and safe, it does not explicitly guide when to use this tool versus alternatives (e.g., search_contacts for searching, contact_get for a single contact). The caching advice 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 indicate idempotent, not read-only, not destructive. The description adds behavioral context such as 'requires user confirmation recommended' and the return of an updated email object, providing extra clarity 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, with a single introductory sentence and a structured list of arguments. Every sentence adds value; 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?
The description explains the return type (updated email object) and raises ValueError/ValidationError. It does not cover prerequisites like authentication status, but for a simple tool with an output schema, it is largely 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?
Despite the schema having 0% description coverage, the description lists each parameter with clear explanations (e.g., 'The email ID to update', 'Microsoft account ID', 'Whether to mark as read (True) or unread (False)'), effectively compensating for the schema's lack of 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 explicitly states the action 'Mark an email as read or unread' and identifies the resource (email), distinguishing itself from the sibling tool email_update by calling itself a simpler alternative for this specific 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 clear guidance by positioning itself as a simpler alternative to email_update for marking read/unread, implying when to use it. It also mentions 'requires user confirmation recommended', but does not exhaustively cover 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?
Adds behavior beyond annotations: notes that it does not delete from source, requires user confirmation, and returns a new email ID. Annotations already indicate non-readonly and idempotent.
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 and well-structured with a clear title, emoji, short explanation, valid folder list, Args, and Returns.
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?
Complete for a simple move operation given the output schema and annotations; could mention behavior for invalid folders or pre-existing emails.
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 0% schema description coverage, the description explains all three parameters (email_id, destination_folder, account_id) and lists valid folder names, adding essential 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 moves an email to a different folder, distinguishing it from sibling tools like email_delete, email_archive, and emailfolders_move.
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 valid folder names and recommends user confirmation, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive. Description adds that user confirmation is recommended and specifies allowed update keys, adding 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?
Well-structured with icon, summary, examples, allowed keys, args, and returns. No fluff, efficient use of text.
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 inputs, allowed keys, examples, and user confirmation. Output schema exists and description mentions 'Updated email object', which is sufficient given the available 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?
With 0% schema description coverage, the description fully explains each parameter: email_id as 'The email ID to update', updates as a dictionary with allowed keys, and account_id as 'Microsoft account ID'. This adds significant meaning beyond schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 updates email properties like isRead, categories, and flags, and explicitly says it does not change email content. This distinguishes it from sibling tools like email_mark_read and email_flag.
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?
Provides a note about user confirmation recommended and gives examples, but does not explicitly guide when to use this tool versus other email siblings like email_mark_read or email_add_category.
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=false and destructiveHint=false, so the description's mention of moving and returning an updated object aligns without contradiction. It adds value by recommending user confirmation, but does not detail side effects like permission changes.
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, using an emoji for quick recognition, and well-structured with Args and Returns sections. Every sentence is informative 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?
Given the presence of an output schema, the description appropriately notes the return type. It covers the main aspects of the operation, though it could mention scope (OneDrive) and authentication requirements more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It lists all three parameters with meaningful labels ('file ID', 'destination folder ID', 'Microsoft account ID') that add context beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Move a file to a different folder' and 'Moves a file to a different parent folder within OneDrive', providing a clear verb+resource combination. It distinguishes from siblings like file_copy or file_delete by specifying 'move' and targeting a different 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 includes 'requires user confirmation recommended', indicating a precondition. However, it does not explicitly contrast with folder_move or specify when not to use this tool. The context is clear enough for the intended 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?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds that it 'creates a sharing link' and requires user confirmation. It also lists raised exceptions (ValueError). This gives the agent useful behavioral context beyond the structured 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, well-structured with a summary line, separate Args/Returns/Raises sections, and no redundant information. 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 the tool's complexity (4 parameters, output schema exists), the description covers purpose, parameter semantics, return values (including web URL), and error conditions. No critical information is missing.
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 input schema has 0% description coverage, so the description fully compensates by detailing all four parameters: file_id, account_id, permission_type (with default 'view'), and scope (with default 'anonymous'), explaining their roles. This adds complete meaning that the schema alone 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 'Create a sharing link for a OneDrive file', specifying the action, resource, and includes a recommendation for user confirmation. It distinguishes itself from sibling file tools like file_copy or file_delete by focusing on sharing links.
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 mentions 'requires user confirmation recommended' but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description adds critical behavioral details: it performs a replacement (modification), validates local_file_path with ensure_safe_path to prevent traversal, and recommends user confirmation. These traits are not fully captured by annotations alone.
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 line summary with emoji, then clear argument and return sections. Every sentence adds value, with no fluff or 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?
Given the tool's complexity (3 required string params, output schema exists), the description covers the operation, parameter details, validation, and user confirmation recommendation. It is complete for an agent to select and invoke correctly, especially with an 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?
With 0% schema coverage, the description fully explains each parameter: file_id is 'target OneDrive file identifier', local_file_path is 'absolute path... validated via ensure_safe_path', and account_id is simply identified. This adds significant meaning beyond the bare schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Replace OneDrive file content with local file', using a specific verb and resource. This distinguishes it from sibling tools like file_copy (copy), file_create (create new), file_delete (delete), etc., 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for content replacement and includes a recommendation for user confirmation. However, it does not explicitly state when to use versus alternatives, nor does it provide exclusions or conditions for use. Sibling tools are not mentioned for comparison.
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 caching details, return fields (childCount, hierarchy), and the force_refresh option, which goes beyond the annotated metadata.
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 summary line, parameter list, and return description. It is slightly long but each sentence adds value. Front-loads the key purpose and safety note.
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 6 parameters and an output schema (though not detailed here), the description covers all inputs and the return structure adequately. Mentions cache status fields which are important for the agent.
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 0% schema description coverage, the description thoroughly explains all 6 parameters with defaults, precedence (folder_id over path), and caching flags. This compensates fully for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 a clear verb ('List only folders') and distinguishes from files and sibling tools like file_list and folder_get_tree. It specifies the scope (OneDrive) and read-only nature.
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 (list folders with hierarchy and child counts) and provides caching options. It does not explicitly state when not to use or compare to alternatives, but the sibling list and context provide implicit 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?
The description adds context beyond annotations: it describes return values (account info or pending status) and the pending nature if user hasn't completed. Given readOnlyHint=false and destructiveHint=false, the description appropriately indicates a mutating but non-destructive operation.
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 clear sentences, an emoji for visibility, and labeled Args/Returns sections. No 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?
Given one simple parameter and an output schema, the description fully covers the tool's purpose, prerequisite, and return possibilities. Complete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides crucial meaning: it explains 'flow_cache' is the flow data returned from account_authenticate (the _flow_cache field). This clarifies the parameter's origin and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 completes device flow authentication, specifying the verb 'Completes' and the resource 'authentication process'. It distinguishes itself from sibling account_authenticate by referencing the prior step and the flow_cache argument.
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 that it is used after the user enters the device code at the verification URL, and that flow_cache comes from account_authenticate. It implies a prerequisite but does not explicitly state when not to use or provide 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 declare readOnlyHint and idempotentHint, so the description reinforces these. It adds value by detailing the return structure (username, account_id, account_type) and providing an example.
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 yet fully informative, using clear sections and an example. 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?
Given no parameters and an output schema, the description sufficiently explains the return values and provides a complete example. Annotations cover safety and idempotency.
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 tool has zero parameters, so the baseline is 4. The description correctly omits parameter details as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 action ('List all signed-in Microsoft accounts') and its resource scope, distinguishing it from sibling tools like account_authenticate that handle authentication.
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 indicates it's 'read-only, safe for unsupervised use,' implying low-risk usage. However, it does not explicitly state when not to use it or suggest alternatives.
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 (destructiveHint=true, readOnlyHint=false), the description adds critical behavioral context: always requires user confirmation, permanent deletion, attendee cancellation notices, and need for confirm parameter to be 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?
The description is efficient and well-structured: opens with a clear action, includes a warning, then lists parameters in a clean args block. No unnecessary sentences.
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 4 parameters, 2 required, destructive, and an output schema. The description covers purpose, irreversibility, attendee notices, parameter meanings, and return confirmation. Lacks mention of error handling or prerequisites but is sufficient for a delete operation.
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 0% schema description coverage, the description fully explains all 4 parameters with purpose and semantics (e.g., account_id as Microsoft account ID, event_id as the event to delete, send_cancellation default true, confirm must be True to prevent accidents).
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 deletes a calendar event, with a permanent irreversible action. This verb+resource combination is distinct from sibling tools like calendar_create_event, calendar_update_event, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting events and warns about permanence and attendee notifications, but does not explicitly state when to use this tool vs alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds permanent deletion warning and confirmation requirement beyond annotations. 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, front-loaded with purpose, uses warnings and emoji effectively. No wasted 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?
Description covers all needed behavioral and usage context for a simple destructive tool with output schema 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?
All three parameters explained with roles and the confirm parameter's required value, compensating for 0% schema 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?
Clearly states 'Delete an email permanently' with explicit warning. Distinguishes from siblings like email_move and email_archive.
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?
Suggests using email_move as safer alternative. Mentions required user confirmation. Could be more explicit about 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 provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds 'safe for unsupervised use' and details return content (conditions, actions, execution order), which adds 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?
Concise, well-structured with overview, args, and returns sections. Front-loaded with key read-only hint. No 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?
Given two simple required parameters and the presence of an output schema (not shown), the description explains return value comprehensively. No gaps for a retrieval 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 0%, but description includes 'Args' section that briefly describes rule_id as 'The message rule ID' and account_id as 'Microsoft account ID', providing essential context for parameter 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?
Clear verb 'Get' and resource 'message rule' with read-only hint. Distinguished from sibling tools that create, delete, or update 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?
Explicitly states read-only and safe for unsupervised use, providing context for when to use. Could explicitly mention alternative tools for writing, but context is clear from sibling names.
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 details beyond annotations: explains the effect on execution order and sequence number, and notes user confirmation. 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-line summary plus structured bullet points for args and returns. No superfluous words; 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?
Covers the action, parameters, return value (updated rule), and context (execution order, user confirmation). With an output schema present, the description suffices for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explicitly defines both parameters (rule_id as the message rule ID, account_id as Microsoft account ID), adding necessary meaning for agent 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 clearly states the tool moves an email rule to the top of execution order, explains the meaning (runs before all others, sets sequence number to 1), and distinguishes it from siblings like move_up, move_down, move_bottom.
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 context about execution order and recommends user confirmation. While it does not explicitly state when to use this over alternatives, the sibling names (move_up, move_down, move_bottom) make the distinction 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 declare readOnlyHint=true and destructiveHint=false. The description adds that the URL expires after a short period and raises ValueError for invalid files, going beyond annotations to disclose important behavioral traits.
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 well-structured with an introductory sentence, Args/Returns/Raises sections. No superfluous content; 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 the tool's simplicity (2 required params, clear read-only behavior, output schema present), the description fully covers input, output, and error conditions without requiring additional detail.
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?
Input schema has no descriptions (0% coverage). The description provides clear, concise explanations for both parameters: 'file_id: The file ID to get download URL for' and 'account_id: Microsoft account ID', adding meaning where 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 identifies the tool as getting a temporary download URL for a OneDrive file, with the verb 'get' and specific resource 'download URL'. It distinguishes from sibling tools like file_get or file_share by focusing on direct download via URL.
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 states it is 'read-only, safe for unsupervised use' and explains the URL is temporary and expires. This provides context for when to use, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safety and idempotency. Description adds routing behavior and search scope details. No contradictions; adds meaningful 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?
Well-structured with emoji summary at top, then details, and a bullet-list of args. Every sentence adds value, no fluff. 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?
Covers search behavior, routing, and parameter details. Output schema exists, so return description is sufficient. Could mention ordering or pagination, but not necessary for this tool.
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 has 0% description coverage, but the description includes a full Arg list with constraints (character limits, ranges, defaults), fully compensating for lack of 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?
Clearly states it's a search tool for calendar events, specifying searched fields (title, location, description) and read-only nature. Differentiated from sibling search tools (contacts, emails, files, unified).
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 context on automatic API routing based on account type and notes read-only safe use. Lacks explicit when-not-to-use or alternative suggestions, but purpose is clear among 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 indicate destructiveHint=true and idempotentHint=true. The description adds context: the action is permanent, cannot be undone, and the confirm parameter prevents accidents. Also explains the error when trying to delete the default calendar.
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 a prominent warning emoji, clear sections for args, returns, and raises. Every sentence adds value, and the warning is front-loaded. No 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?
Covers all essential aspects: preconditions (default calendar not deletable), required confirmation, permanent nature, and error cases. The output schema (not shown) is likely sufficient, and the description explains return type and raises. Complete for this destructive operation.
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 input schema has 0% description coverage, but the description fully explains each parameter: account_id, calendar_id, and confirm (with its role in preventing accidents). Provides clear 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 clearly states the action: 'Delete a calendar permanently.' It specifies the resource (calendar) and includes a warning about data loss. Distinguishes from sibling tools like calendar_create_calendar and calendar_delete_event by focusing on 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 notes that the default calendar cannot be deleted and requires user confirmation via the 'confirm' parameter. However, no explicit alternatives are given for cases where deletion is not intended, though siblings provide other calendar operations.
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?
Discloses that the tool 'replaces all existing categories with the specified ones' – a key behavioral trait not captured by annotations. Also lists raised errors (ValueError, ValidationError). Annotations indicate destructiveHint=false, but the replacement behavior could be considered destructive; however, the description is transparent about this.
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?
Front-loaded with emoji and key info. Each sentence serves a purpose: purpose, usage guidance, behavioral warning, args, returns, raises. No redundant text.
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 all aspects: purpose, behavior, parameters, return value, and error handling. Has output schema, so return details are sufficient. Complexity low, but description is complete.
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?
With 0% schema description coverage, the description fully compensates by describing each parameter in the Args section: email_id, account_id, and categories, adding context beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Add categories to an email' with a specific verb and resource. Distinguishes itself from sibling 'email_update' by noting it is a 'simpler alternative for managing email categories'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance by recommending use as a simpler alternative to email_update and mentions user confirmation. However, does not explicitly state when not to use or list other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutability (readOnlyHint=false) and safety (destructiveHint=false). The description adds valuable behavioral context like the recommendation for user confirmation, return format note, and potential errors, going 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 emoji-tagged purpose line, one comparative guidance line, and a clear Args/Returns/Raises block. Every sentence earns its place, and the core action is front-loaded.
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 simple tool nature and presence of an output schema, the description covers all bases: purpose, parameter semantics, behavior (user confirmation), sibling differentiation, and error handling. No gaps remain.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, default value, and possible values for flag_status (listed as options). This adds meaning that the raw 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 the tool's purpose: 'Flag or unflag an email' with a specific verb and resource. It further distinguishes from sibling 'email_update' by positioning itself as a 'Simpler alternative for flagging emails,' making the unique 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 directs agents to use this tool for flagging when they would otherwise consider 'email_update,' and recommends user confirmation. It lacks explicit guidance on when not to use it, but the comparison covers key 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?
Beyond annotations (destructiveHint=true, idempotentHint=false), description adds that deletion is permanent, cannot be undone, and folder remains. 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?
Well-structured with clear sections (purpose, warning, args, returns, raises), uses bold and emoji for emphasis, every sentence is necessary and concise.
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 an output schema exists and the description includes Returns and Raises, it fully covers operation, parameters, behavior, and errors, making it complete.
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 0%, but description fully explains all three parameters: folder_id, account_id, and confirm (clarifying it must be True to prevent accidents, overriding schema default of false).
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Delete all messages in a folder' with the verb 'Empty' and resource 'Email Folder', distinguishing it from siblings like 'email_delete' (single email) or 'emailfolders_delete' (delete 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?
Provides explicit warning about permanent deletion, requires user confirmation via 'confirm' parameter, and notes the folder remains. However, does not explicitly compare to alternative tools like 'emailfolders_delete'.
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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by confirming it is 'safe for unsupervised use' and details metadata like unread counts and child folder information, beyond what annotations convey.
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 a front-loaded purpose indicated by an emoji. It is structured into clear Args and Returns sections, with each sentence adding necessary information. No redundancies.
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 4 parameters, one required, and an output schema available, the description provides complete context: it explains the return structure (list of folder objects with fields) and all parameter behaviors. There are no gaps for safe 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?
The input schema has 0% description coverage, meaning the JSON schema itself lacks parameter descriptions. The description compensates fully by explaining each parameter: account_id as Microsoft account ID, parent_folder_id's null vs provided behavior, include_hidden default, and limit's range and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 mail folders from a mailbox with a read-only safe behavior. It distinguishes itself from siblings like emailfolders_get (detail) and emailfolders_get_tree (hierarchy) by focusing on listing either root or 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 explains when to use root vs child folder listing via the parent_folder_id parameter. It does not explicitly state when not to use, but sibling names imply alternatives for specific folder details or tree structure.
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 cover readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by detailing body truncation at 50,000 characters, caching freshness (15 min fresh, 1 hour stale), and the effect of force_refresh. 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 well-structured, using emojis for visual cues, bullet points for clarity, and front-loading the key purpose. Every sentence adds value without unnecessary verbosity.
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 7 parameters, presence of output schema, and annotations, the description is thorough. It covers return values including _cache_status and _cached_at, and explains caching behavior, making it complete for the tool's complexity.
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 description coverage is 0%, but the description explains all 7 parameters: email_id, account_id, include_body, body_max_length, include_attachments, use_cache, and force_refresh, including defaults and purpose. This fully compensates for the lack of 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 it retrieves detailed information about a specific email, specifying it's read-only and safe for unsupervised use. It distinguishes itself from sibling tools like email_list and email_get_attachment by focusing on a single email with full 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 provides guidance on caching behavior and when to use force_refresh. It also implies safe usage (read-only, unsupervised). However, it does not explicitly mention when not to use this tool versus alternatives like email_list.
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 read-only, non-destructive, idempotent, and open-world. The description adds caching details (10 min fresh, 1 hour stale) and force_refresh option, and mentions _cache_status and _cached_at fields in return, exceeding annotation information.
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 (description, caching, args, returns) using emoji and bullet points. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high annotation coverage and presence of output schema, the description is complete. It documents all parameters, caching behavior, and return fields, leaving no ambiguity for the agent.
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 0% schema coverage, the description provides a detailed 'Args' section explaining each of the 7 parameters with defaults and meanings, fully compensating for the missing 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?
Clearly states it lists files and/or folders in OneDrive, is read-only, and returns names, sizes, and dates. Distinguishes from sibling tools like search_files and folder_list by specifying listing of both files and 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?
Provides usage context (read-only, safe for unsupervised use) and caching behavior, but lacks explicit guidance on when not to use it or alternatives such as search_files for searching across files.
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 goes beyond annotations by detailing automatic routing, caching behavior (use_cache, force_refresh), and return type. It reinforces the readOnlyHint and adds operational 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections and bullet points, but includes an emoji and slightly verbose phrasing (e.g., '📖 Search emails across mailbox (read-only, safe for unsupervised use)'). Still, it remains 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?
The description covers purpose, parameters, routing, caching, and safety. With an output schema present, it doesn't need to detail return format. Missing details on pagination or handling large result sets, but overall sufficient for a search tool.
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 has zero parameter descriptions, but the tool description compensates thoroughly, explaining each parameter's purpose, constraints (e.g., query length, limit range), defaults, and examples (e.g., folder options). This provides essential semantic information for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: search emails across mailbox with specific scope (subject, body, sender). It differentiates from siblings like email_list, email_get, and other search tools by emphasizing the search capability and automatic API routing based on account type.
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 it's read-only and safe for unsupervised use, providing clear context for when to use. However, it does not mention alternatives like search_unified or when not to use this tool, which would improve 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 critical behaviors: immediate sending, irreversibility, validation, deduplication, recipient limit of 500, and the need for confirm=True. Annotations (readOnlyHint=false, destructiveHint=false) are consistent and the description adds substantial context beyond 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 concise and well-structured: a header line, a crucial warning, then a list of parameters with explanations. No extraneous information; 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?
The description covers purpose, usage, parameter details, behavioral warnings, errors, and return type. Given the tool's complexity (6 params, sending action) and the presence of an output schema, the description is complete and self-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?
With 0% schema description coverage, the description adds meaning by explaining each parameter (e.g., 'to: Recipient email address(es)', 'confirm: Must be True to confirm sending'). It also mentions validation and limits. However, it does not detail format for account_id or event_id, missing some depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Forward a calendar event to recipients,' clearly identifying the verb and resource. It is distinct from sibling tools like email_forward (email) and calendar_respond_event (response), so an agent can differentiate it.
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 important usage instructions: user confirmation required, immediate sending, irreversibility, and recipient limits. It does not explicitly contrast with alternative tools, but the context and warning provide adequate guidance for 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds caching specifics (5 min fresh, 30 min stale), force_refresh option, and confirms it is safe for unsupervised use. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for caching, parameters, and returns. It is concise without unnecessary words. Slightly verbose due to full parameter listing, but this is justified given 0% schema coverage.
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 (6 parameters, output schema exists), the description is complete. It covers caching, parameter details, safety, and return fields like _cache_status. The output schema covers event properties, so no additional detail needed.
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 input schema has 0% description coverage, but the description manually documents all 6 parameters with defaults, ranges (1-365 for days_ahead, 1-200 for limit), and semantics (e.g., include_details for full event details). This fully compensates for the missing 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 it lists upcoming calendar events from now until a specified number of days ahead. It uses specific verb-resource ('List Calendar Events') and distinguishes from siblings like search_events or calendar_get_event by focusing on upcoming events from a specific 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 provides context: it is read-only and safe for unsupervised use, and explains caching behavior. However, it does not explicitly state when not to use this tool or mention alternatives like calendar_get_event for single events or calendar_get_free_busy for availability checks.
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 (destructiveHint=true, readOnlyHint=false), the description adds critical behavior: 'WARNING: This action permanently deletes the folder and all its contents (emails and subfolders) and cannot be undone.' It also clarifies the confirm parameter requirement, which is 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 structured with a clear warning, parameter list, and returns/raises sections. Each sentence serves a purpose, though the multiple warnings could be slightly condensed without losing clarity.
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 destructive nature (destructiveHint=true) and the output schema presence, the description covers all necessary aspects: purpose, usage warnings, parameter semantics, return values, and error conditions. It leaves no critical gaps for an AI agent.
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 0% schema description coverage, the description fully explains each parameter: folder_id (the folder ID), account_id (Microsoft account ID), and confirm (must be True to confirm). It also documents the ValueError for invalid folder_id or false confirm, adding semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a mail folder permanently' and includes a warning about permanent deletion. It distinguishes itself from sibling tools like emailfolders_create, emailfolders_rename, and others by specifying the destructive nature.
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 notes that the action 'always require[s] user confirmation' and warns about permanent deletion. It implicitly guides usage by emphasizing the need for caution, though it does not explicitly list alternatives 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: forwarding is immediate and irreversible, addresses are validated/deduplicated with a 500 limit, confirm must be true. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections: emoji line, warning, validation info, Args list, Returns, Raises. It is slightly lengthy but each sentence adds value. Front-loaded with purpose and warning.
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 6 parameters, output schema exists, and no enums, the description covers behavior, validation, parameter requirements, and error conditions comprehensively. Returns are summarized as 'Status confirmation', sufficient since output schema exists.
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?
With 0% schema description coverage, the description fully compensates by listing all parameters with explanations: account_id (Microsoft account ID), email_id, to/cc (recipients), body (optional plain text), confirm (must be True). Provides meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Forward an email to recipients', which is a specific verb and resource. It distinguishes itself from sibling tools like email_send (send new email) and email_reply by specifying forwarding an existing email with an optional comment.
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 implies when to use (forwarding) and includes warnings and constraints, but does not explicitly compare to alternatives like email_send or email_reply. However, the context from sibling tools makes it fairly 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?
Beyond annotations (readOnlyHint, etc.), the description adds caching details (2 min fresh, 10 min stale), return field information, and parameter behavior (force_refresh). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Returns, Caching, Args) and an emoji for visual cue. It is slightly verbose but each sentence adds value. Front-loading with purpose is 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 7 parameters, output schema presence, and sibling tools, the description covers all aspects: function, parameters, caching, return format, and safety. No gaps remain.
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 0% but the description's Args section thoroughly explains each parameter: account_id, folder (with allowed values), folder_id, limit (with range), include_body, use_cache, force_refresh. This adds meaning far 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 'List emails from a mailbox folder' with a specific verb and resource. It distinguishes from siblings like email_get (single email) and email_send. The emoji and 'read-only' further clarify 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 indicates this is 'read-only, safe for unsupervised use' and explains caching behavior. However, it does not explicitly contrast with alternatives like search_emails or when not to use it, slightly reducing clarity.
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 have destructiveHint=false, but the description explicitly warns that the action cannot be undone and sends immediately. This adds crucial behavioral context beyond annotations, with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an emoji header, warning, and docstring-style sections. It is informative but slightly verbose; could be more concise.
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 mutation tool with output schema and 4 parameters, the description covers all critical aspects: purpose, usage constraints, parameter semantics, return values, and errors. No gaps remain.
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 description coverage is 0%, but the description provides full parameter explanations in the Args section, including that 'confirm' must be True and 'body' is stripped of whitespace. This compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Reply to all recipients of an email', indicating a specific verb and resource. It implies differentiation from the sibling 'email_reply' by specifying 'all' recipients.
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 warning that reply will be sent immediately to all recipients and cannot be undone, guiding use. It also notes user confirmation is required, but does not explicitly 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds critical behavioral details beyond annotations: requires confirmation (confirm param), permanent deletion, and impact on email processing. Annotations already indicate destructive and idempotent, but description enriches 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?
Well-structured with emoji, warnings, args, returns. Every sentence adds value; no fluff. Efficiently communicates all necessary 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?
Given output schema exists, return values need no elaboration. Description covers destructive nature, parameter semantics, and consequences, making it complete for agent selection and 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 0% schema description coverage, description compensates by explaining rule_id, account_id (Microsoft account ID), and confirm (must be True to prevent accidents). Provides meaning beyond type/required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Delete a message rule permanently', with a verb and specific resource. Distinguishes from sibling tools like emailrules_create, emailrules_update, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Warns that action requires user confirmation and cannot be undone. While it doesn't explicitly contrast with other tools, the clear purpose and warnings imply appropriate 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?
Discloses immediate sending, irreversibility, recipient validation, deduplication, 500 recipient limit, and confirmation requirement. Annotations do not contradict; destructiveHint=false is consistent as sending is not data destruction. Rich behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with warning, details, args, returns. Front-loaded with critical info. Slightly verbose (e.g., 'Addresses are validated...' could be part of param description), but still efficient and clear.
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 7 parameters, output schema exists, and no nested objects, the description covers purpose, behavior, all parameters, return values (by referencing status), and errors (ValidationError). No gaps.
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 0%, but description adds full meaning for all 7 parameters, including types, purpose, constraints (validation, dedup, limit), and the critical confirm parameter. Compensates excellently for missing 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?
Clearly states 'Send an email to recipients' with immediate sending and irreversibility. Differentiates from siblings like email_create_draft by emphasizing sending vs drafting. Specific verb and resource.
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 requires user confirmation and warns of immediate irreversible action. Context is clear for sending, but no direct mention of when not to use (e.g., for draft use email_create_draft). Still strong 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 key behaviors: user confirmation, security validation (allow-list of Microsoft domains), streaming, chunking, retry, and environment variable controls. This adds value beyond the annotations (which show idempotentHint=true, etc.) by explaining actual execution behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Args, Returns, Raises) and front-loads the core purpose. While it is comprehensive, it could be slightly more concise without losing important details. Every sentence adds value, making it a strong 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?
Given the three parameters, no nested objects, and presence of an output schema, the description is remarkably complete. It covers parameter validation, security, error handling, environment variables, and return format. No gaps are evident.
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?
With schema coverage 0%, the description fully compensates by clearly defining each parameter: file_id, account_id, download_path (including constraint 'Must reside within an allowed root directory'). It also describes the return dictionary and exception types, providing rich semantics beyond the bare 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: 'Download a OneDrive file to a local path'. This is a specific verb ('download') and resource ('OneDrive file' with local path). It distinguishes from sibling tools like 'file_download_url' by emphasizing the actual download to disk and mentioning user confirmation.
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 notes 'requires user confirmation recommended' and mentions environment variables for size/timeout limits, giving guidance on when to use. However, it does not explicitly state when not to use or compare with alternatives like 'file_download_url', so it falls 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true. Description adds details: 'permanently delete', 'cannot be undone', 'always require user confirmation'. 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?
Well-structured with sections for args, returns, raises. Slightly verbose but every sentence adds value. Front-loaded with warning.
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 behavior, parameters, return value, and error conditions (ValueError). Output schema exists, but description mentions return type. Complete for a destructive tool.
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 0%, but description fully explains all 3 parameters: folder_id, account_id, and the confirm flag (must be True). Adds 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?
Clear verb 'Delete' and resource 'OneDrive Folder'. Distinguishes from sibling tools like folder_create, folder_rename, file_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns about permanence and requires user confirmation via the confirm parameter. Does not explicitly compare to alternatives but provides clear 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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds caching behavior (30 min fresh/2 hours stale), force refresh option, and return fields like _cache_status. This significantly enriches behavioral 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 well-structured with emoji, line breaks, and sections (caching, args, returns). Every sentence earns its place, though it is slightly verbose. Front-loaded key purpose and safety note.
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 6 parameters, existence of output schema, and complexity of building a tree, the description covers purpose, usage context, caching, all parameters, and return structure including cache metadata. It is complete and informative.
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?
With 0% schema coverage, the description provides detailed parameter meanings: account_id, path (default ''/''), folder_id (takes precedence over path), max_depth (1-25, default 10), use_cache, force_refresh. This adds substantial value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recursively builds a tree of OneDrive folders (read-only, safe for unsupervised use). It specifies the verb 'build a tree' and the resource 'OneDrive folders', and distinguishes from sibling tools by highlighting its read-only nature and hierarchical output.
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 mentions the tool is 'useful for understanding OneDrive folder organization' and provides caching details, but does not explicitly state when not to use it or offer alternatives like folder_list. It gives context for use but lacks exclusion criteria.
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, etc.), the description explains the Graph API prefix matching limitation, caching behavior, and that it is safe for unsupervised use. 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, well-structured with an emoji header, clear sections, and a bullet list of arguments. Every sentence adds value, and the structure aids quick understanding.
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 output schema exists, the description adequately covers search behavior, caching, parameter constraints, and limitations. It is complete for a read-only search tool without needing to detail return 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?
Despite 0% schema description coverage, the description explains all parameters: query as a prefix string (1-512 chars), account_id, limit with range and default, and cache flags. Missing details like account_id format, but overall adds sufficient 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 searches contacts by names, emails, and phone numbers, and distinguishes from sibling tools by specifying contact-specific search. It also mentions it's read-only and safe, using a specific verb 'search' and a clear resource 'contacts'.
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 indicates when to use the tool (for searching contacts) and notes limitations like prefix matching, but it does not explicitly contrast with sibling tools like contact_list or search_unified. However, the context makes it clear that this is for search with filtering.
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 valuable context: automatic API routing based on account type, caching behavior via use_cache and force_refresh, and the safe read-only nature, exceeding 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 well-structured with a lead summary, followed by details and clearly labeled Args/Returns sections. 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?
The description covers purpose, usage, parameters, and return format. Output schema exists, but description still summarizes return format. Missing edge cases or error handling, but sufficient for a search tool with rich annotations.
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 has 0% coverage (no descriptions), but the description provides clear, concise explanations for all 6 parameters, including types, defaults, and constraints (e.g., query 1-512 chars, limit 1-500). This fully compensates for missing 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 it searches multiple M365 resources (emails, events, files) simultaneously, with a specific verb and resource. It distinguishes from siblings like search_emails, search_events, etc. by using 'unified' and explaining simultaneous search.
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 indicates when to use it (multi-resource search, read-only, safe) and provides account type routing behavior. It doesn't explicitly mention alternatives but the grouping of sibling tools implies this is for combined searches.
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?
Reinforces annotations (readOnlyHint, idempotentHint) with readable safety note. Describes return format and example, adding value beyond structured fields.
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 compact paragraphs plus an example. Emoji and front-loaded key info. No filler.
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 parameters and rich annotations/output schema, the description covers all needed context: purpose, usage, return structure, and example.
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; schema coverage 100%. Baseline 4 is appropriate as description need not add param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 server version, a specific verb-resource pair. No sibling tool does this, so it stands out distinctly.
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 says it's for diagnostics, troubleshooting, and compatibility. No need for when-not since it's read-only and safe.
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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds 'read-only, safe for unsupervised use' and fully documents the return format (list of task dictionaries with fields), providing useful context 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?
Well-structured with an initial summary line, then Args, Returns, and Examples sections. Every sentence adds value, no fluff or repetition. Front-loaded with key 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?
Even with an output schema, the description details return fields. Covers purpose, safety, parameters, output, and examples. Complete for a read-only listing tool.
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 description coverage is 0%, but the description thoroughly explains each parameter (account_id, status, limit) with purpose, types, and defaults, plus examples. Fully compensates for missing 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?
Clearly states 'List background cache tasks' with verb and resource, and adds 'read-only, safe for unsupervised use' to distinguish it from mutation tools. Siblings like cache_invalidate are clearly different.
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?
Implies usage by detailing filtering options and providing examples, but does not explicitly compare to alternatives like cache_task_get_status. No '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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description reinforces this by stating 'read-only, safe for unsupervised use' and explains the output type ('availability view strings'), adding value beyond the structured 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, starting with a emoji-summarized safety note, then a clear explanation, sibling comparison, and structured Args section. 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?
With an output schema present, the description only needs to hint at returns, which it does ('Free/busy information with availability view strings'). It also lists possible exceptions. For a simple read tool with 5 params and rich annotations, it is fully complete.
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 description coverage is 0%, but the description provides clear explanations for all five parameters in the Args section (e.g., 'ISO format' for start/end, 'default: 30' for time_interval), compensating fully for the bare 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 'Get simplified free/busy times for attendees' with a specific verb ('get'), resource ('free/busy times'), and scope ('for attendees'). It also distinguishes from the sibling tool calendar_check_availability, ensuring 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly compares itself to calendar_check_availability, noting it 'focuses on availability view strings rather than detailed schedule information,' which guides selection. However, it does not provide explicit when-not-to-use or alternative scenarios beyond that one comparison.
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: caching details (15 min fresh, 1 hour stale), return fields (_cache_status, _cached_at), and safety guarantee. Annotations already declare readOnlyHint=true, which the description reinforces.
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 well-structured with sections (Args, Returns), uses an emoji for quick scanning, and is concise without redundancy. 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?
Despite the output schema existing but not shown, the description adequately describes the return format (list of calendar objects with metadata, including _cache_status and _cached_at). It covers caching, parameters, and return behavior completely for the tool's complexity.
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?
With schema description coverage at 0%, the description fully explains all parameters: account_id as Microsoft account ID, use_cache (default True), force_refresh (default False), adding 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 lists all available calendars for the user, using a specific verb ('List') and resource ('calendars'). It is distinct from sibling tools like calendar_create_calendar or calendar_list_events.
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 about when to use the tool (e.g., read-only, safe) and caching behavior (fresh vs. stale), but does not explicitly state when not to use it or contrast with alternatives beyond the implied domain.
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 mutability and idempotency, but the description adds crucial behaviors: user confirmation is recommended, and attendees receive update notifications. This goes beyond the structured metadata and helps the agent anticipate real-world 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 brief yet covers purpose, usage, parameters, and behavior. It uses a clear structure with an introductory sentence, a bullet list of allowed keys, and an Args section. 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?
Given the presence of an output schema, the description does not need to detail return values. It already covers all necessary aspects: what the tool does, when to use it, what fields to update, and behavioral side effects (user confirmation, notifications). No gaps remain.
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 input schema lacks descriptions for all three parameters (0% coverage). The description compensates thoroughly by listing allowed update keys (subject, start, end, location, body) and providing brief explanations for event_id, updates, and account_id. This makes parameter usage 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 the tool updates an existing calendar event, listing specific properties like time, location, and attendees. This verb+resource combination uniquely identifies the tool among siblings (create, delete, get, list), making 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 provides context for when to use the tool (to modify event details) and mentions side effects (notifications sent). However, it does not explicitly exclude scenarios like proposing new times or responding to events, though these are distinct operations handled by sibling 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?
The description explicitly confirms read-only behavior ('safe for unsupervised use'), matching annotations. It adds valuable behavioral context: recursion with depth control (max_depth 1-25), handling of parent folder as root, and hidden folder inclusion. This goes beyond what annotations (readOnlyHint, idempotentHint) convey.
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 well-structured with an emoji for quick scanning, a one-line summary, then clearly labeled Args and Returns sections. Every sentence adds value, with no unnecessary repetition. It is front-loaded with the key purpose and safety note.
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 presence of an output schema (not shown but confirmed), the description sufficiently explains what the tool does, its parameters, and the hierarchical return. It addresses safety (read-only), recursion limits, and hidden folder control, making it complete for an AI agent to use correctly.
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?
With 0% schema description coverage, the description fully compensates by detailing each parameter: account_id, parent_folder_id (None=root), max_depth (1-25, default 10), include_hidden (default False). This adds critical meaning beyond the bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 ('Recursively build'), resource ('tree of mail folders'), and scope ('read-only, safe for unsupervised use'). It effectively distinguishes the tree-building functionality from sibling tools like emailfolders_list (likely flat) and emailfolders_get (single 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 notes the tool is 'useful for understanding mailbox folder organization,' which implies a hierarchical exploration use case. However, it does not explicitly specify when to avoid this tool in favor of alternatives (e.g., emailfolders_list for flat listing or emailfolders_get for a single folder). The guidance is clear but lacks exclusion criteria.
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 behavioral context beyond annotations: automatic API routing based on account type, caching behavior (use_cache, force_refresh), and that it searches both file names and content. 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 well-structured with a header, a brief paragraph, then a parameter list. Every sentence adds value; no redundancy. It is concise yet comprehensive.
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 output schema exists, the description need not explain return values. It covers input params, caching, routing, and safety. Complete for a search tool.
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 0% schema coverage, the description provides detailed parameter descriptions including constraints (1-512 characters, 1-500 limit) and defaults. All 5 parameters are explained meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 searches for files in OneDrive, specifies it's read-only and safe, and mentions automatic routing by account type. It distinguishes from sibling tools like search_emails or search_contacts.
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?
It explicitly says 'read-only, safe for unsupervised use' and describes automatic routing, giving clear when-to-use guidance. However, it does not explicitly state when not to use it versus alternatives like search_unified.
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:

[![m365-mcp MCP server](https://glama.ai/mcp/servers/robin-collins/m365-mcp/badges/card.svg)](https://glama.ai/mcp/servers/robin-collins/m365-mcp)

Score Badge

Copy to your README.md:

[![m365-mcp MCP server](https://glama.ai/mcp/servers/robin-collins/m365-mcp/badges/score.svg)](https://glama.ai/mcp/servers/robin-collins/m365-mcp)

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/robin-collins/m365-mcp'

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