MS 365-21V MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
The domain prefixes (mail_, calendar_, drive_, etc.) and resource-specific verbs make most tools clearly distinct. However, generic search_* tools overlap with domain-specific search tools (e.g., mail_search_messages vs search_mail), which could cause misselection if the agent isn't careful.
Naming Consistency4/5
The majority of tools follow a consistent domain_verb_noun pattern (e.g., mail_list_messages, calendar_create_event, drive_delete_item). Deviations exist: auth_* tools use a different structure, smart_* tools lack a verb, and confirm_execute has no domain prefix, but these are exceptions among 153 tools.
Tool Count1/5
153 tools is extremely excessive, far beyond the 25+ threshold for a 'too many' rating. A typical MCP server should have a focused set; this one attempts to cover an entire suite, making discovery and selection overwhelming for an agent.
Completeness3/5
The server covers CRUD for mail, calendar, contacts, drive, SharePoint, and Teams, and provides read operations for users and groups. However, notable gaps exist: there is no mail_update_draft or mail_update_message, no upload session tool for large files, and no user/group write operations, which would be expected given the broad scope.
Average 3.8/5 across 153 of 153 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions a permission requirement ('Requires delegated Mail.Read'), which is useful, but it does not disclose other behavioral traits such as whether hidden folders are included by default, if it returns only immediate children, or if it has pagination limits. The tool's read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with the core purpose stated in a single sentence. The inclusion of Chinese intents adds a slight redundancy but may serve a purpose for international users. Overall, it is well-structured and front-loaded, earning a high score despite the minor extra line.
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?
This is a simple list operation, and the description covers the essential function and a key prerequisite (Mail.Read permission). However, it does not mention the return format or any default behaviors (e.g., hidden folders, max results). Given the absence of an output schema and annotations, a bit more detail would make it complete, but it is acceptable for a basic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for all three parameters (top, folderId, includeHidden), so the baseline is 3. The description text adds no additional parameter-level information beyond the schema, leaving the agent to rely on the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List child folders under a mailbox folder.' It uses a specific verb ('List') and resource ('child folders'), which is immediately understandable. However, it does not explicitly distinguish this from the sibling tool mail_list_folders, though the 'child' qualifier strongly implies the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools like mail_list_folders or explain scenarios (e.g., drilling down a folder hierarchy). The usage context is merely implied by the phrase 'under a mailbox folder,' which is not sufficient 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?
With no annotations, the description carries the full burden of behavioral disclosure. It does state 'sends as the signed-in user' and 'requires delegated Mail.Send', but it does not warn that this sends a real, irreversible email or disclose side effects like saving to Sent Items (which is only in the schema). The action is a mutation with significant impact, yet the description omits 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 two concise sentences, front-loaded with the action and permission, and includes a helpful Chinese intent phrase for multilingual support. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema, the description lacks essential context for a mutation tool: no usage guidelines, no warning about irreversibility, and no mention of what the tool returns (since there is no output schema). It only covers the permission requirement, leaving the agent under-informed for selecting and invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains all parameters (subject, body, to, cc, bcc, bodyIsHtml, saveToSentItems). The description adds no parameter-level semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send an email as the signed-in user', which is a specific verb+resource. However, it does not explicitly distinguish itself from sibling tools like mail_send_draft or mail_reply, though the action of sending a fresh email is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as mail_send_draft or mail_reply. It only mentions the permission requirement, which is a prerequisite rather than usage context. There is no when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It mentions the delegated Calendars.ReadWrite requirement, but does not state that deletion is irreversible or clarify whether it affects the whole series or a single occurrence. For a destructive operation, this is insufficient.
Agents need to know what a tool does to the world before 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 three short sentences: purpose, permission requirement, and Chinese intent aliases. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple (one parameter, no output schema), the description fails to distinguish 'delete' from the closely related sibling 'calendar_cancel_event'. It also doesn't mention whether deletion is permanent or affects only specific event types, leaving ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a clear description for 'eventId' ('Calendar event ID.'). The description adds no additional parameter context beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a calendar event') with a specific verb and resource. However, it does not differentiate from the sibling tool 'calendar_cancel_event', which likely performs a similar operation. This gives clear purpose but no distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'calendar_cancel_event'. The description only states a permission requirement, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, but it only states the action. It does not disclose that it returns immediate children, is a read-only operation, supports pagination via `top`, or what the response structure will be. This leaves the agent to infer core 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 primary sentence is concise and front-loaded. The Chinese intents line is redundant as a direct translation, but it may serve multilingual intent matching. Overall, the description is compact and efficient, though not maximally so.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what the response contains or how to use the results. It does not describe return fields, pagination limits beyond the `top` property, or any other context needed to make full use of the tool. This is a significant gap for a listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds little beyond schema: it frames `parentItemId` as 'selected OneDrive folder' but does not clarify `top` or any parameter nuances. It is adequate but not additive to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('files and folders under a selected OneDrive folder'), clearly distinguishing it from sibling tools like `drive_list_root`, `drive_list_recent`, and `drive_search_items`. The Chinese intent line reinforces the same purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool over alternatives, no exclusions, and no prerequisites. It merely implies usage by mentioning 'selected OneDrive folder', but does not describe navigation context or compare with other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and provides no details on what happens to the current version, whether a new version is created, permissions required, or reversibility. The Chinese intents merely restate the purpose, adding no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one English sentence and a Chinese translation. It is front-loaded with the essential purpose and does not waste words, though the Chinese portion is repetitive but justifiably included for multilingual support.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description must provide sufficient context for a mutation tool. It lacks any explanation of versioning behavior, side effects, or prerequisites, making it incomplete for an agent to fully anticipate the consequences of calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since all three parameters have descriptions, so the baseline is 3. The tool description adds no further parameter semantics beyond what is already in the schema, which is acceptable given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool restores a historical version of a SharePoint document-library file, using a specific verb and resource. It distinguishes from the sibling drive_restore_version by explicitly mentioning SharePoint document-library context.
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 SharePoint file version restoration but does not explicitly state when to use this tool over alternatives like drive_restore_version. No exclusions or alternative guidance is provided, so usage is implied rather than clearly directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states the action without any details about side effects, permanence, permissions, or error conditions. For a destructive operation like deletion, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the primary English statement first and a redundant Chinese translation second. It is front-loaded, uses no filler, and each part serves a purpose (the Chinese aids multilingual intent recognition).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no output schema and no annotations. The description does not explain what happens after deletion, whether the action is reversible, or any prerequisites. Context such as the need to have an existing attachment ID or the impact on the event would improve completeness, but these are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for both parameters ('Event ID.' and 'Attachment ID.'), yielding 100% coverage. However, these descriptions are tautological with the parameter names. The tool description itself adds no further meaning about where to find these IDs or how they relate, but since the schema covers them, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete an attachment from a calendar event.' It uses a specific verb and resource, distinguishing it from siblings like mail_delete_attachment and calendar_list_attachments. The Chinese intent phrase reinforces the purpose without adding ambiguity.
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. For example, it does not mention that one first needs to obtain attachment IDs via calendar_list_attachments, or that deletion is permanent. There is no exclusion or alternative context, leaving the agent to infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic function. It does not describe return value shape, timezone handling, limitations (e.g., max instances), or behavior for non-recurring events.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is concise and front-loaded. The additional Chinese intent phrases ('查看重复会议实例', etc.) may aid multilingual intent matching but are somewhat redundant for an AI agent evaluating tool semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with fully covered parameters and no output schema, the description is minimally viable. However, it lacks context around edge cases (e.g., non-recurring events), timezone behavior, and result ordering, which could matter for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description aligns with the startDateTime/endDateTime fields but adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource structure ('List occurrences of a recurring event in a date-time range') and clearly distinguishes this tool from sibling calendar tools like calendar_list_events or calendar_get_event by focusing on recurring event instances.
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. It does not mention exclusions, prerequisites, or cases where other calendar tools would be more appropriate.
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?
With no annotations, the description must disclose behavioral traits. It states the deletion but omits critical consequences such as whether contacts inside the folder are also deleted, whether the action is reversible, or whether specific permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one English sentence and one Chinese localization sentence. Both are purposeful and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive one-parameter tool with no output schema and no annotations, the description is too sparse. It fails to mention important operational context such as cascading deletion of contained contacts or irreversibility, leaving the agent without sufficient information to anticipate consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes folderId as 'Contact folder ID to delete' with 100% coverage. The description adds no additional parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Delete a personal contact folder.' This clearly distinguishes it from sibling tools like contacts_create_folder, contacts_update_folder, and contacts_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are any prerequisites, exclusions, or context provided. The description only states the action without explaining typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the basic operation but adds no details about behavior such as whether it returns only direct folder members, if pagination is needed, or if any side effects occur. The description is minimal and largely redundant with the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point. The additional Chinese intent phrases add some bulk but are not excessive, and the main sentence is efficient. It is not overly verbose, meriting a score above the minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description covers the core purpose, and the schema fully documents parameters. However, it lacks any usage guidance or behavioral context beyond what the tool name implies, so it is only minimally complete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'top' and 'folderId' documented in the input schema. The description does not add additional meaning to these parameters beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'List personal contacts in a selected contact folder.' This specifies the verb (list), the resource (personal contacts), and the scope (in a selected folder), distinguishing it from sibling tools like contacts_list (lists all contacts) and contacts_list_folders (lists folders).
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. It does not mention contacts_list, contacts_search, or contacts_list_folders, nor does it give any context about prerequisites or exclusions. The Chinese intents merely offer synonyms for the same action, providing no usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'List personal contact folders' and does not describe the return format, whether system folders are included, pagination behavior, or authentication requirements. This is a minimal description with no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a single English sentence and a Chinese translation. The Chinese text repeats the meaning and may be useful for multilingual intent matching, but it is not essential. Overall, the description is front-loaded and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema), a basic description might suffice, but this one omits any indication of what the returned data looks like or how the response is structured. It also doesn't clarify the exact scope of 'personal contact folders' or if it excludes shared contacts. The description meets the minimum viable standard but lacks contextual richness.
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 sole parameter 'top' is fully documented in the schema with a description ('Number of folders to return') and constraints (minimum 1, maximum 100), providing 100% schema coverage. The tool description adds no further semantic meaning to this parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'personal contact folders', clearly distinguishing the tool from sibling tools like contacts_list_folder_contacts which lists contacts within a folder. The scope 'personal' disambiguates from shared or public folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that contacts_list_folder_contacts is for contacts within folders, nor does it state any prerequisites or exclusion criteria. The tool's name partially implies its use case, but the description itself lacks usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'search personal contacts by name prefix' without disclosing read-only nature, case sensitivity, pagination, or error behavior. The Chinese intent examples do not add behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, the first being the core functionality. The second sentence lists Chinese intents, which is extra but not harmful; however, it could be seen as slightly unnecessary. Overall, it is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with fully described schema, the description is minimally adequate. It does not describe return values (no output schema) or usage context, nor does it mention alternatives. However, the purpose is straightforward, so it is not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats 'name prefix' but adds no additional meaning beyond what the schema already provides for query and top parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches personal contacts by name prefix, which is a specific verb and resource. It distinguishes from sibling tools like contacts_list or contacts_get by detailing the search scope (personal contacts) and method (prefix).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not mention when to use this tool instead of alternatives such as contacts_list or contacts_get. It gives no explicit context, exclusions, or alternative recommendations. The only hint is the prefix search nature, which implies use for partial name lookups, but this is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the required roles, which is useful behavioral context, and implies read-only search behavior. However, it does not detail pagination behavior, result ordering, or error handling, leaving transparency gaps.
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, front-loaded with the core purpose, and includes essential permission information. The Chinese intents add minor redundancy but serve a useful purpose for multilingual users, so it remains efficient without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with three well-documented parameters, the description provides the core purpose, query syntax, and required permissions. It does not explain return format, but the absence of an output schema makes this less critical. It is reasonably 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters (query, from, size) already documented in the schema. The description adds no extra parameter semantics beyond restating the Microsoft Search query syntax, which is already in the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches calendar events using Microsoft Search query syntax, providing a specific verb and resource. However, it does not explicitly differentiate from sibling tools like calendar_list_events or search_mail, so it falls short of the highest rating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions required roles (mcp.search and mcp.calendar) but does not provide guidance on when to use this tool versus alternatives such as calendar_list_events or other domain-specific search tools. There is no explicit when-to-use or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'List all members' without detailing output format, pagination, permissions, or whether bots/guests are included. The read-only nature is implied by 'list' but not explicitly disclosed.
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 one concise sentence that front-loads the core action. The appended Chinese intents provide multilingual equivalency without redundancy, keeping the text appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description is minimally sufficient. However, it lacks a distinction from team/channel member tools and does not describe return values, which would be helpful given no annotations and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter chatId having a description ('Teams chat ID.'). The tool description adds no parameter information, but the high schema coverage justifies the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all members of a Teams chat' uses a specific verb and resource, clearly identifying the tool's function. The 'Teams chat' qualifier distinguishes it from sibling tools like teams_list_team_members and teams_list_channel_members.
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 usage guidance is provided. The description does not specify when to use this tool versus alternatives such as teams_list_team_members or teams_list_channel_members, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Rename a personal contact folder.' It does not disclose behavioral traits such as whether the rename is permanent, whether it affects existing contacts, or if any special permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating the operation, followed by a concise Chinese translation. It is appropriately sized and every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two self-explanatory parameters and full schema coverage, so the description is minimally sufficient. However, it lacks contextual details such as whether the folder must be a personal folder vs. a system folder, or any side effects, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage with descriptions for both parameters (folderId and displayName), so the description does not need to add much. However, the description adds no additional parameter-level meaning beyond what the schema already states, meriting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rename) and the object (personal contact folder), distinguishing it from sibling tools like contacts_create_folder and contacts_delete_folder. The Chinese translation reinforces the same intent without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as creating or deleting a folder. It does not mention any prerequisites, exclusions, or context in which renaming is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While 'restore' implies returning to a previous version, the description does not disclose that this overwrites the current version, is potentially irreversible, or requires specific permissions. This is a significant gap for a mutating operation, though the name gives a partial clue.
Agents need to know what a tool does to the world before 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 English sentence is concise and front-loaded, stating the action in one line. The additional Chinese intent list provides useful aliases for multilingual routing while remaining compact; no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 required params, no output schema), but because it performs a destructive restore and lacks annotations, the description should explain the effect on the current file and any prerequisites. The current description only states what it does, not the consequences, leaving a completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with clear descriptions (itemId and versionId from drive_list_versions), so the baseline is 3. The description adds no additional meaning beyond what the schema provides, merely referencing 'selected historical version' which maps to versionId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Restore') and resource ('historical version of a OneDrive file'), clearly distinguishing it from sibling tools like drive_list_versions or drive_download_file. The Chinese intent aliases reinforce routing without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to alternatives like drive_list_versions or drive_download_file. It does not mention that a version must first be selected from drive_list_versions, nor any exclusions such as file types or permission requirements. This lack of usage context makes it difficult for an agent to decide between related drive operations.
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?
With no annotations provided, the description must carry the full burden. It adds the scope of 'Microsoft Entra or Microsoft 365 group' but does not disclose return format, potential empty results, pagination behavior, or any permission requirements. Minimal behavioral detail is given beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with additional Chinese intent phrases. Every part is purposeful and adds value, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description is sufficient for a basic list operation but could benefit from mentioning pagination, default top value, or typical return structure. Overall, it is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (groupId, top) described. The description adds no additional parameter nuance, so the baseline of 3 applies as the schema already provides adequate 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 'List owners of a Microsoft Entra or Microsoft 365 group', using a specific verb and resource. It distinguishes from sibling tools like groups_list_members by focusing on owners, and is further reinforced by the title 'List Group Owners'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as groups_list_members or groups_get. The Chinese intent phrases imply usage scenarios but do not explicitly exclude sibling tools or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses an important prerequisite: 'Requires both mcp.search and mcp.sharepoint roles.' This is a behavioral context (auth requirement). However, it does not explicitly state that the operation is read-only, mention result pagination behavior, or note any access limitations beyond the role requirement. The role note adds value, but other behavioral traits remain undisclosed.
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, consisting of a core sentence, a role requirement, and a set of Chinese intent phrases. While the Chinese portion might be unnecessary for some users, it is not verbose and provides alternative phrasings for multilingual intent matching. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description does not describe what the response contains, how to paginate through results, or any query syntax nuances. With sibling tools like search_files and sharepoint_search_sites, more context on result shape or usage boundaries is needed. The description feels thin for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters (query, entityType, from, size), so the schema already documents parameter meaning. The description adds no additional parameter-level details beyond what is in the schema, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Search SharePoint sites or list items with Microsoft Search.' This uses a specific verb and resource, and the scope (sites or list items) distinguishes it from sibling tools like sharepoint_search_sites and sharepoint_search_drive_items. The Chinese intent examples further clarify the intended usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as sharepoint_search_sites or search_files. It does not mention criteria for choosing this tool over search_mail or search_teams, nor any exclusions. The Chinese intents hint at use cases but do not contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is asynchronous, which is valuable, but fails to explain what that means for the caller (e.g., how to check progress or what response to expect). It also does not state whether the source item is left unchanged (implied by 'copy' but not explicit) or any permission requirements. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core purpose stated in the first sentence and additional multilingual intents in the second. It is front-loaded and contains no filler. The Chinese intents, while somewhat repetitive, are useful for matching Chinese-language queries and do not detract from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain the return value, how the asynchronous operation is tracked, or whether there are any side effects on the source item. The schema covers parameters but not runtime behavior or results. The description should provide more context for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with clear descriptions for all four parameters, so the baseline is 3. The description adds no new parameter-level information; it only mentions copying a file/folder, which is already covered by the schema. There is no additional semantics like value ranges or parameter dependencies beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies a SharePoint file or folder, with a specific verb ('Copy') and resource ('SharePoint file or folder'), and adds the important distinguishing detail 'asynchronously'. The inclusion of Chinese intents helps clarify the target domain and usage, making it distinct from generic drive copy tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for copying SharePoint items, but does not explicitly provide alternatives or exclusions. It does not mention when to prefer this tool over similar siblings like drive_copy_item or sharepoint_move_drive_item, leaving the agent to rely on the name and purpose rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the required permission (Sites.Manage.All) but does not describe other behavioral traits such as idempotency, conflict behavior, or return value. Since annotations are absent, the description carries the burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded, and free of fluff, though the Chinese intent line is redundant. It remains concise and efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations; the description omits what the tool returns on success, error conditions, and any side effects other than creation, leaving significant gaps for a non-trivial operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage of all three parameters, and the description only reinforces the definition parameter by mentioning it as a Microsoft Graph columnDefinition, adding little 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 'Create a SharePoint list column from a Microsoft Graph columnDefinition,' specifying the verb, resource, and input format. This distinguishes it from sibling column operations like sharepoint_update_column and sharepoint_delete_column.
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 instead of alternatives such as sharepoint_update_column or sharepoint_delete_column. The only contextual note is the required permission (Sites.Manage.All), which is not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior, but it only states the action and intended outcome ('resolve site', 'get Site ID'). It does not specify return format, error conditions, or whether any side effects occur, leaving the agent guessing about the operation's safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The Chinese repetition is somewhat redundant for a general agent but serves a multilingual audience, and the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool, the description covers the basic action and required inputs, and it hints at the output ('Site ID'). However, with no output schema, it lacks details on response structure, error scenarios, or permission requirements, making it minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'hostname' and 'server-relative path' but adds minimal detail beyond the schema. The relativePath parameter already has a schema description, while hostname lacks one and the description does not compensate with examples or format hints. With 50% schema coverage, the description provides little added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a SharePoint site using hostname and server-relative path, with a specific verb ('resolve') and resource. It distinguishes the operation from sibling tools like sharepoint_get_site (likely by ID) by focusing on path-based lookup.
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 when a hostname and relative path are available, reinforced by the Chinese intent of parsing a SharePoint link. However, it does not explicitly mention alternatives or exclusions, such as when to use sharepoint_search_sites instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only restates the action without disclosing behavioral details such as read-only nature, required permissions, hidden column inclusion, or return format. The description does not add context beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and uses minimal words. The additional Chinese intents are redundant but not verbose, maintaining efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, no output schema, and no annotations, the description is adequate but lacks completeness. It states the purpose and parameters clearly, but omits return structure and usage context, which are important for a tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides clear descriptions for both siteId and listId, covering 100% of parameters. The description adds no additional parameter semantics, but the schema suffices, so this meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists column definitions and internal names for a SharePoint list, specifying both the resource (SharePoint list columns) and the output. This distinguishes it from sibling tools like sharepoint_create_column or sharepoint_list_list_items.
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. There is no mention of prerequisites, typical use cases, or related tools for listing items or creating columns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that the tool lists sharing and permission entries, but it does not disclose whether this is a read-only operation, whether it requires specific admin or owner permissions, whether the returned entries are scoped to a particular permission type, or any rate limiting or pagination behavior. For an API that surfaces sensitive access-control data, this is a notable gap.
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 core English statement, followed by Chinese translations for common intents. It is concise (two sentences) and every part adds context, though the Chinese phrases could be seen as redundant for an English-speaking agent but are valuable for multilingual intent coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is relatively brief but does state the core behavior. However, for a security-sensitive tool that lists permissions, it would benefit from explaining what information appears in the results (e.g., user/group identities, roles, links), potential exceptions, and whether it covers both direct and inherited permissions. The sibling named drive_list_permissions is likely similar, so additional differentiation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters ('File or folder item ID' and 'Document-library drive ID'), so the schema already explains the parameters. The description adds meaning by confirming the operation is for a SharePoint file or folder and that it lists sharing/permissions, which helps contextualize how itemId and driveId are used without needing to repeat the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('list') and resource ('sharing and permission entries for a SharePoint file or folder'), which distinguishes it from other SharePoint listing tools that focus on items, drives, or versions. It does not explicitly contrast with sibling tools, but the phrase 'sharing and permission entries' makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a basic sense of when to use the tool (to view permissions or access on SharePoint files/folders) via both English and Chinese intents. However, it does not include explicit guidance on when to use this instead of related tools like drive_list_permissions or sharepoint_invite_drive_item, nor does it mention any prerequisites such as required permissions.
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?
With no annotations provided, the description carries the full burden for disclosing behavior. It mentions the permission requirement (delegated Files.ReadWrite.All), which is useful, but fails to explain what 'small' means (file size limit), what happens on conflict despite the conflictBehavior parameter existing, or what response/return value to expect. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose stated first and permission next. The Chinese intents are extra but add multilingual accessibility without bloating the text. It is appropriately sized, though the Chinese part is somewhat redundant and contains a character corruption (保��文件), which slightly detracts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations. The description explains purpose and permission but is incomplete for a mutation tool. It does not mention how to obtain driveId, what size limit 'small' refers to, the default conflict behavior, or the shape of a success response. This is inadequate for an AI agent to invoke it confidently in a real workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema—only emphasizing the 'path relative to the library root' concept, which is already in the schema. It does not enhance understanding of contentEncoding or conflictBehavior beyond their enum 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 states a specific verb ('Upload'), resource ('SharePoint document library'), and method ('using a path relative to the library root'). It clearly distinguishes this from the sibling drive_upload_small_file by specifying SharePoint rather than a generic drive.
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 uploading small files to SharePoint libraries and mentions the required permission, but it does not explicitly compare to alternatives like drive_upload_small_file or state when to use this versus other SharePoint file operations. There is no explicit '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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action, but does not mention required permissions, potential errors, idempotency, or consequences of adding an existing member. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The Chinese intent lines are repetitive but take little space and may aid multilingual users. Every sentence contributes to localization, though the first sentence alone would suffice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about prerequisites, return values, or failure modes. It only explains the basic operation, leaving the agent without guidance on how to handle edge cases or verify success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add any parameter-level semantics beyond the schema, such as the meaning of roles or how to obtain team/channel IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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') and the specific resource ('a member or owner to a private Teams channel'). This distinguishes it from sibling tools like teams_add_team_member and teams_add_chat_member, which operate on different scopes. The mention of 'private' channel adds important 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 context by stating it is for private Teams channels, but does not explicitly contrast with alternatives or provide when-not-to-use guidance. It is clear enough for an agent to infer the appropriate scenario, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the destructive action ('Delete') but does not disclose irreversibility, permission requirements, or side effects. This is a significant gap for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the core English phrase. The Chinese translations add minor redundancy but are not excessive, making it still concise and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a simple delete operation, the description could explain the result of deletion, error scenarios, or whether it is permanent. It does none of this, leaving the agent to infer the full behavioral context from the tool name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters teamId and channelId are already fully documented. The description adds no additional semantic value beyond what the schema provides, which aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a Microsoft Teams channel' with a specific verb and resource, clearly distinguishing it from sibling tools like teams_create_channel or teams_update_channel. The additional Chinese intent translations reinforce the meaning without adding ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the deletion action, but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. It does not name alternative tools for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It mentions the size limit and base64 encoding, but does not describe the expected outcome (append vs replace), error handling for oversized files, permission requirements, or side effects. This leaves significant behavioral ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the essential English statement and appending a Chinese translation that aids non-English users. There is no wasted information; every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the six parameters, no annotations, no output schema, and the presence of sibling tools for attachments (mail_add_file_attachment, calendar_list_attachments, etc.), the description is incomplete. It lacks context on prerequisites, relationship to other attachment tools, and inline attachment behavior, making it insufficient for an agent to fully understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the input schema. The description reiterates the base64/size constraint already present in the contentBase64 field, adding no new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a base64-encoded file under 3 MB to a calendar event.' It specifies the resource (calendar event) and the operation (add file attachment), distinguishing it from email attachment tools like mail_add_file_attachment because of the explicit 'calendar event' 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 its use case—adding attachments to calendar events—but provides no explicit guidance on when to choose this over alternatives such as mail_add_file_attachment. The Chinese intents are simple translations, not usage context. No exclusions or alternative suggestions are given.
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?
With no annotations, the description carries the full burden. It indicates a mutating rename action but does not disclose potential side effects, permission requirements, reversibility, or whether the calendar ID changes. This is a significant transparency gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the English purpose and followed by a Chinese translation. It is concise and free of fluff; the Chinese addition is a useful localization but somewhat redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename tool with two well-documented parameters and no output schema, the description covers the basic purpose. However, the absence of annotations and behavioral details like error cases or effects on sharing make it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for both parameters, so the baseline is 3. The description adds minimal value beyond the schema, only clarifying the calendarId refers to a signed-in user's calendar. It does not explain how to obtain the calendarId or additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Rename one of the signed-in user calendars' with a specific verb and resource, clearly distinguishing it from create/delete calendar operations and event updates. The title 'Rename Calendar' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage on the signed-in user's own calendars, but provides no explicit when-to-use or alternatives. It does not reference sibling tools such as calendar_create_calendar or calendar_delete_calendar, so guidance is only implicit.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that creating a sharing link alters item permissions, may require specific authorization, or whether the action is reversible. For a mutation tool with potential security implications, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and includes helpful Chinese intent variations without redundancy. Every word earns its place, and no unnecessary detail is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and a security-sensitive operation. The description does not explain what the tool returns (e.g., the share link URL), nor does it clarify edge cases like link scope or permissions. Given the complexity and risk, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to add parameter details. The description adds no additional meaning beyond the schema, but the schema itself fully documents all four parameters, justifying the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a sharing link') and the specific resource ('SharePoint file or folder'), which distinguishes it from the similar drive_create_share_link tool. The inclusion of Chinese intents reinforces the tool's purpose for Chinese-speaking users.
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 this tool is for SharePoint content, but it does not explicitly say when to use it over alternatives like drive_create_share_link. No mention of when-not-to-use or prerequisites is provided, so guidance is only implied by the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the required permission (Sites.Manage.All) and implies only custom columns are affected, but it does not mention irreversibility, consequences for existing data, or behavior if the column is in use. This is partially transparent for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by the required permission. The Chinese intent variants are somewhat repetitive but serve multilingual intent matching. Overall, it is appropriately sized with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with fully documented parameters and no output schema, the description covers the core purpose and permission. However, it lacks explicit warnings about permanence or the restriction to custom columns, leaving some important operational context unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (siteId, listId, columnId) with 100% coverage. The description adds no extra parameter-level detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a custom SharePoint list column') with a specific verb and resource. It distinguishes this tool from sibling column tools like sharepoint_create_column and sharepoint_update_column.
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 gives no explicit guidance on when to use this tool versus alternatives, nor any exclusions like 'do not use for system columns' or prerequisites beyond the permission. The user must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose 'Requires delegated Sites.Manage.All', which is useful authorization context. However, it does not state that deletion is irreversible or that all items in the list are also removed, which is critical for a 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, front-loaded with the core action and permission, and includes compact multilingual intents. It avoids redundancy and every part serves a purpose for agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation, the description lacks critical context: no warning about permanent data loss, no mention of cascading deletion of list items, and no post-conditions or confirmation of what happens after execution. While it covers permissions and scope, it is incomplete for safe 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?
Both parameters (siteId and listId) are fully described in the input schema, providing 100% schema coverage. The description adds no additional parameter-level semantics, such as how to obtain the IDs or any constraints, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an entire SharePoint list', providing a specific verb ('delete') and resource ('entire list'). The word 'entire' distinguishes it from item-level deletion tools like sharepoint_delete_list_item, and the Chinese intents reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as sharepoint_delete_list_item or sharepoint_delete_drive_item. It only mentions the permission requirement (Sites.Manage.All) but does not provide usage context, exclusions, or alternative tool references.
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?
With no annotations, the description carries the transparency burden. It adds the meaningful qualifier 'retained versions' (not all versions), which is a useful behavioral distinction. However, it does not disclose output format, pagination, permissions, or ordering, though these are likely inherent to a simple list operation.
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, containing a clear one-sentence summary plus a Chinese intent alias section. The Chinese text is arguably useful for multilingual intent matching but is not essential. Overall, it is well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 fully described parameters, no output schema, no annotations), the description provides a minimally viable context. It explains what versions are listed but lacks detail on return structure or usage scenarios, which would be helpful for agents encountering similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both driveId and itemId described adequately in the schema. The tool description does not add additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (list) and resource (retained versions of a SharePoint document-library file). It clearly distinguishes from sibling tools like drive_list_versions by explicitly mentioning SharePoint document-library, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives such as drive_list_versions or sharepoint_restore_drive_version. The SharePoint qualifier implicitly suggests context, but there is no comparative direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Rename a file or folder' without mentioning side effects, permanence, permissions, or error behavior. It does not contradict anything, but it also adds minimal behavioral context beyond the obvious mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the core English sentence first and Chinese translations appended for multilingual support. No unnecessary words or repetition. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations and no output schema, the description should explain what happens after the rename (e.g., successful response, updated item) or any prerequisites. It only states the action, leaving out behavioral expectations like whether the rename is immediate or if there are restrictions. This is a notable gap for a simple but state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (driveId, itemId, newName) are fully described in the input schema (100% coverage). The description adds no additional parameter-level detail, so it relies entirely on the schema, which is adequate. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rename') and identifies the exact resource ('file or folder in a SharePoint document library'). This clearly distinguishes it from sibling drive_rename_item (which targets OneDrive/Drive) and sharepoint_move_drive_item. The Chinese intent strings further reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for SharePoint document libraries, which differentiates from the generic drive_rename_item. However, it does not explicitly say when to prefer this over alternatives, nor does it mention any exclusions or prerequisites. The context is clear but not contrasted with siblings.
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?
With no annotations provided, the description carries the full burden. It states 'Read' which indicates a non-mutating operation, but it does not disclose additional behavioral traits such as required permissions, error behavior, or what is returned. Minimal disclosure beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with the English purpose front-loaded. The Chinese intent examples are supplementary and add value for multilingual support without being verbose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description is adequate but not fully complete. It does not clarify what 'details' includes or what the response structure looks like, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both teamId and channelId, though minimal. The tool description adds no parameter-level semantics beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read details for one Microsoft Teams channel' clearly specifies the verb (read), resource (Microsoft Teams channel), and scope (one specific channel). It effectively distinguishes from sibling tools like teams_list_channels (which lists channels) and teams_get_team (which gets a team).
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 when you need details for a specific channel, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. No alternatives or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only clarifies that it lists direct members and channel types, but does not mention whether it is read-only, requires specific permissions, or how pagination works. This is insufficient for an agent to fully understand the tool's 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 a single concise sentence followed by a helpful Chinese intent phrase. It is front-loaded with the core purpose, and every element adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain return values and behavioral details. It lacks any information about what the response contains, pagination, or error conditions, making it incomplete for an agent to fully understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (top, teamId, channelId) are fully documented in the schema. The description adds no parameter-specific information beyond this, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists direct members of a Teams channel, specifying the channel types (standard, private, shared). This distinguishes it from sibling tools like teams_list_team_members and teams_list_chat_members, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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, nor does it mention exclusions. However, the 'direct members' qualifier implies a distinction from team-level member listing, providing indirect context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only adds scope constraints (direct, private) but does not mention side effects (permanent removal), required permissions, failure conditions, or any special member ownership considerations. This is insufficient for a mutating action.
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 English sentence is concise and front-loaded with the action. The Chinese intent examples add length but serve multilingual fallback; they are not essential but not overly verbose either. Overall, the description is efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 params, no output schema), the description covers the key scope (private channel, direct member) but misses behavioral context such as reversibility and permissions. It is adequate for basic invocation but not fully comprehensive for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters. The description adds no additional parameter-level semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the specific resource ('direct member from a private Teams channel'), which distinguishes it from sibling tools like teams_remove_team_member or teams_add_channel_member. The scope is precise: direct membership and private channels only.
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 context by specifying 'direct member' and 'private channel', but does not explicitly state when to use this tool versus alternatives (e.g., teams_remove_team_member for team-level membership). No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses no behavioral traits such as irreversibility, permission requirements, or side effects. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The Chinese intents are somewhat redundant but not harmful, keeping it concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is minimally viable but lacks usage context, behavioral transparency, and alternative guidance. It is adequately clear for basic invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for both chatId and membershipId, so the description adds no additional parameter meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove a member') and resource ('Teams group chat'), clearly distinguishing it from related tools like teams_remove_team_member or teams_remove_channel_member. The Chinese intent phrases reinforce the same meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for group chats, which differentiates it from sibling tools, but it does not provide explicit when-to-use guidance or mention exclusions. It also does not reference the prerequisite of first listing members via teams_list_chat_members.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose that removal is irreversible, may require permissions, or what consequences occur for the removed member. This is a significant gap for a potentially destructive mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single English sentence plus concise Chinese intent phrases, all front-loaded and free of fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal action with two fully documented parameters and no output schema, the description is sufficient. Its only shortcoming is the lack of behavioral transparency, but the action itself is uncomplicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters adequately described. The membershipId description even references its source (teams_list_team_members), so the tool description adds no additional 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?
States 'Remove a member from a Microsoft Teams team' — a specific verb and resource, clearly distinguishing it from sibling tools like teams_remove_channel_member and teams_remove_chat_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only states the action without contextual usage advice.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'personal' folder, but does not mention side effects, permissions, return values, or any requirements. For a create operation, this is a minimal disclosure and misses opportunities to clarify behavior beyond the obvious action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: an English statement and a Chinese translation. Both are concise, front-loaded with the main action, and contain no redundant information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is minimally sufficient. However, the lack of annotations means more context would be helpful, such as prerequisites or when to use it. The current description is adequate but does not exceed expectations for a simple create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the sole parameter displayName, which is clearly described as 'Contact folder name.' The description adds no extra parameter information, but the baseline of 3 applies because the schema already handles the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a personal contact folder' with a specific verb and resource, distinguishing it from sibling tools like contacts_create (creating a contact) and contacts_delete_folder (deleting a folder). The Chinese intents are an additional language clue, enhancing 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 implies the tool is used when creating a contact folder, but it does not explicitly discuss alternatives or provide exclusion criteria. No guidance is given on when to use this versus other folder-related tools, though the name and context make it somewhat obvious.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Read complete details', which conveys a read-only operation, but does not clarify error handling, permission requirements, or what 'complete details' entails. This is minimal disclosure for a tool with no annotation support.
Agents need to know what a tool does to the world before 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 the main action front-loaded in the first sentence. The added Chinese intent mapping is a minor extra but does not add fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description explains the core purpose. However, it does not describe return value structure or any edge cases (e.g., non-existent contact), leaving the agent without full context for what to expect.
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 for contactId is 100% with a basic description ('Contact ID'). The tool description adds context that it's for a personal contact, which is marginal. Since the schema already documents the parameter, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Read') and clearly defines the resource ('complete details for one personal contact'). This distinguishes it from sibling tools like contacts_list and contacts_search, which are for listing and searching, not fetching a single contact's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single contact detail lookup, but it does not explicitly state when to choose this tool over alternatives such as contacts_list or contacts_search, nor does it mention exclusions or prerequisites like having a valid contactId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it requires delegated Files.Read permission, which is useful. As a list operation, the verb implies read-only behavior, but it does not discuss other behavioral aspects such as response shape, pagination, or handling of empty permission lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with additional Chinese intents. It is front-loaded with the core action and includes the auth requirement, but the Chinese translation section adds bulk without new information for English agents.
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 simple one-parameter tool, the description covers the purpose, auth scope, and general resource type. It does not specify return format, but the name and description imply the output is permission metadata; no output schema is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter itemId is described in the schema as 'OneDrive item ID.' The description reinforces that it applies to a file or folder but adds no further semantics beyond the schema, so the baseline for full schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with resource 'permission and sharing metadata for a file or folder in the signed-in user OneDrive', clearly identifying its scope. The mention of 'signed-in user OneDrive' distinguishes it from the SharePoint permission listing sibling (sharepoint_list_drive_permissions).
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. It states a required permission (Files.Read) but does not explain scenarios, prerequisites, or exclusions relative to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clearly states 'Read details', indicating a read-only operation, which is useful. However, it does not describe the return format, the exact identifier format expected for groupId, or any potential error conditions, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the English purpose. The Chinese intent list adds length but serves a clear i18n purpose. Every sentence earns its place, though the intent list could be seen as slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation, the description is largely sufficient when combined with the schema. It identifies the resource type and action. It lacks details on return shape and usage alternatives, but given the tool's simplicity, this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes groupId as 'Group ID' at 100% coverage, so the baseline is 3. The description adds context that the group is a Microsoft Entra or Microsoft 365 group, but does not specify the format (e.g., object ID, UPN, mail address) beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Read details for a Microsoft Entra or Microsoft 365 group.' This clearly distinguishes the tool from sibling group tools like groups_list, groups_list_members, and groups_list_owners, which focus on listing or membership operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives. The description does not mention that groups_list can find group IDs, or that groups_list_members/owners are separate tools for specific group-related queries, so an agent gets no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the required permission (Sites.Manage.All) and notes that only 'writable properties' can be updated, but does not describe what happens on error, whether it is idempotent, or what the return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with two sentences covering purpose and permission. The Chinese intent lines are redundant for English-speaking agents but serve a specific audience, making it slightly less concise than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a flexible 'definition' object, no annotations, and no output schema. The description does not mention the return type or expected behavior after update, nor does it enumerate any example properties. This leaves the agent uncertain about the outcome and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all four parameters (100% coverage), so the description adds nothing beyond what the schema states. The description does not explain the 'definition' object structure beyond the schema's 'Only the column properties to update.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 action ('Update'), the resource ('SharePoint list column'), and the scope ('writable properties'). This distinguishes it from sibling tools like sharepoint_create_column, sharepoint_delete_column, and sharepoint_update_list.
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 over alternatives, nor does it mention exclusions. The permission requirement is noted, but no guidance on when to prefer this over related tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It does disclose the need for delegated ChannelMessage.Read.All and tenant admin consent, which is useful. However, it does not describe return format, pagination behavior, or ordering beyond 'recent'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes only essential permission information and Chinese intents. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain return values. It does not, beyond implying recent messages. The tool is relatively simple with 3 documented params, but missing details on response fields or pagination leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with descriptions for top, teamId, and channelId. The description adds no further parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List recent messages in a Teams channel', using a specific verb and resource. It distinguishes from sibling tools like teams_list_channel_message_replies and teams_send_channel_message. Chinese intents also clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions required permissions but gives no guidance on when to use this tool versus alternatives. It does not reference sibling tools such as teams_list_channel_message_replies or teams_list_channel_members.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that the calendar is 'additional' and scoped to the 'signed-in user,' clarifying that it does not create a shared or delegated calendar. However, it does not mention permission requirements, duplicate-name behavior, or what the response returns, leaving notable gaps for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core English description is a single, front-loaded sentence that delivers the purpose efficiently. The Chinese intent block is redundant but compact and serves intent-matching for non-English queries, so it does not meaningfully harm readability or structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter creation tool, the description plus full schema coverage cover the essential semantics of what the tool does and what input it takes. However, with no annotations and no output schema, the description does not disclose the return value, required auth scopes, or behavior on duplicate names, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter `name` with 100% coverage, so the schema carries the descriptive burden. The description adds no parameter-level semantics beyond what the schema already states, warranting the baseline score of 3 for high 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?
The description states 'Create an additional calendar for the signed-in user,' providing a specific verb (create), resource (calendar), and scope (additional, user-scoped). This clearly distinguishes it from siblings like calendar_create_event, calendar_list_calendars, and calendar_update_calendar. The Chinese intent phrases reinforce the same meaning without introducing ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'additional calendar' and 'signed-in user,' suggesting when it applies. However, it offers no explicit when-not-to-use guidance, no exclusions, and no pointer to alternatives like calendar_update_calendar or calendar_delete_calendar for related operations. Usage is inferred rather than stated.
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?
With no annotations, the description must disclose behavior fully. It does state the significant side effect that deleting the calendar also deletes its events, which is useful. However, it does not mention irreversibility, permission requirements, or other potential impacts like shared access removal, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is a single, front-loaded sentence: 'Delete an additional calendar and its events.' It is concise and free of fluff. The Chinese intents line is a compact, purposeful addition for multilingual support 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 simple delete operation with one parameter, the description is mostly complete. It covers the primary action and the cascade to events. However, it lacks an explicit warning about permanence or any prerequisites. Since there is no output schema and the main effect is clear, it is reasonably complete but could be stronger.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a clear description for calendarId ('Calendar ID to delete.'). The tool description adds no further meaning, format, or usage detail for the parameter. Per the rubric, with high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with a specific verb ('Delete') and resource ('calendar'), and adds the key detail that it also deletes the calendar's events. This distinguishes it from sibling tools like calendar_delete_event and calendar_update_calendar. The qualifier 'additional' also hints at scope, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that deleting individual events should use calendar_delete_event, nor does it state restrictions (e.g., primary calendar cannot be deleted). The context is implied but not spelled out, leaving the agent to infer usage.
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?
With no annotations, the description must carry the transparency burden. It clearly states the core side effect (granting read/write access) and the optional invitation. However, it does not disclose whether existing permissions are replaced, whether the caller needs special ownership rights, or what happens if recipients already have access. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core English action, and the Chinese intent mapping adds useful multilingual coverage without unnecessary verbosity. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the 100% schema coverage, and the absence of an output schema, the description provides enough context for an agent to understand the action and its optional invitation behavior. It could be improved by noting how this relates to permission replacement or invite vs. share-link flows, but it is not incomplete for selection purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds semantic context by mentioning 'selected people' (recipients), 'read or write access' (roles), and 'optionally send an invitation' (sendInvitation), but it does not add detail beyond what the schema already provides for message, itemId, or requireSignIn.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: 'Grant selected people read or write access to a OneDrive item and optionally send an invitation.' This uses a specific verb and resource, and the mention of OneDrive plus 'selected people' distinguishes it from sibling tools like drive_create_share_link (link-based sharing) and sharepoint_invite_drive_item (SharePoint-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. For example, it does not clarify whether to prefer this over drive_create_share_link for link-based sharing or sharepoint_invite_drive_item for SharePoint items. Usage context is only implied by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose authorization requirements and the search backend, which is useful. However, it does not explicitly state that this is a read-only operation, describe return format, or mention any search limitations or side effects. Some transparency is present, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by a concise requirement statement and a Chinese intent line. It is appropriately sized and mostly efficient, though the Chinese intent section is somewhat redundant for an AI agent but adds multilingual value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description explains purpose and role requirements, but does not clarify what the search returns, pagination behavior beyond schema hints, or the scope of the search (e.g., all Teams or joined teams). Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description ('Zero-based result offset', 'Number of search hits to return', 'Microsoft Search query string'). The tool description adds no additional parameter-specific meaning, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a specific resource ('Microsoft Teams chat messages'), and the method ('with Microsoft Search'). This clearly distinguishes it from sibling tools like search_mail or teams_list_chat_messages. The Chinese intents reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching Teams messages and provides a prerequisite ('Requires both mcp.search and mcp.teams roles'), but it does not explicitly mention when to use this vs alternatives like search_mail or teams_list_chat_messages, nor any exclusions. Thus, usage is implied rather than clearly guided.
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?
With no annotations, the description carries the full burden of transparency. It discloses that this is an administrative write and specifies the required permission, which is useful. However, it does not mention the return value, behavior if the list name already exists, or any side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core purpose in one sentence and permission in a second. The Chinese intents add a bit of length but serve a multingual purpose and do not feel wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a 5-parameter mutation tool with no output schema, the description is only partially complete. It covers the essential purpose and permission, but lacks information about return values, error handling, or how this relates to other sharepoint tools like sharepoint_create_list_item. The schema fills in parameter details, but the description does not fully compensate for the missing output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning; it does not even name the parameters, relying entirely on the schema for their documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a SharePoint list' clearly, with a specific verb and resource. This distinguishes it from sibling tools like sharepoint_create_list_item and sharepoint_update_list, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'administrative write requires delegated Sites.Manage.All', providing clear context that this is a privileged operation. However, it does not explicitly contrast with alternatives like sharepoint_update_list or sharepoint_delete_list, so the guidance is implied rather than explicit.
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?
With no annotations, the description carries the transparency burden. It discloses the required permission (delegated Files.Read.All) and implies read-only behavior via 'List'. However, it does not mention pagination limits, return format, or behavior for invalid driveId/folderId, which are relevant for an agent. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is two concise sentences: the action and the permission requirement. The included Chinese intent phrases add length but serve a localization purpose and do not obscure the main statement. It is front-loaded and efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward list operation, and the description covers what it lists and the permission needed. However, it does not explain what the response contains or how pagination works, and there is no output schema to fill that gap. Given the sibling toolset, this description is adequate but leaves room for edge-case details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters described in the input schema. The description adds minimal parameter-level insight beyond restating 'root or folder', which is already conveyed by parentItemId's 'Defaults to the library root'. Baseline 3 applies because the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('files and folders in a SharePoint document library root or folder'), clearly scoping the operation. It distinguishes from siblings like drive_list_root (which targets OneDrive/Drive) and sharepoint_search_drive_items (which is for search) by emphasizing 'SharePoint document library'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it lists, and it mentions a prerequisite (delegated Files.Read.All). However, it provides no explicit when-not-to-use guidance or alternatives (e.g., use sharepoint_search_drive_items for searching, or drive_list_children for a user's drive). The context is clear but not directive.
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?
With no annotations provided, the description must disclose behavioral traits itself. It does include a required permission ('Requires delegated Sites.Read.All') and a performance hint about filters, which adds value. However, it omits details about pagination, default page size, sorting, or what happens when fieldNames is omitted—gaps that are not covered by the schema's brief field descriptions.
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 primary purpose and remains concise. The Chinese intent list adds lengthy synonym phrases, which may be useful for multilingual queries but is somewhat redundant for an AI agent. The overall structure is clear and the essential information is presented early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description is adequate but not thorough. It covers the core action and a permission requirement, but does not explain pagination behavior, the default return size, or the effect of fieldNames on the response. These gaps are partially mitigated by the schema's field descriptions, but the description itself could be more complete given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description's filter tip ('Optional filters work best on indexed columns') is already echoed in the schema's filter description ('Prefer indexed columns'), so it adds no new parameter semantics. No other parameter guidance is provided in the description, leaving it at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb and resource: 'List items and field values in a SharePoint list.' This distinguishes it from sibling tools like sharepoint_get_list_item (singular item) and sharepoint_list_item_delta (incremental changes). The Chinese intents reinforce the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an implied usage context—listing SharePoint list items—and a practical tip about filters on indexed columns. However, it does not explicitly state when to use this tool over alternatives like get_list_item or list_item_delta, nor does it mention any exclusions or prerequisites beyond the permission note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosure. It only restates the action without revealing side effects, required permissions, idempotency, or failure behavior. There is no added value beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the key information front-loaded. The additional Chinese intent lines are compact and provide multilingual support without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is minimal. It does not explain expected result, error cases, prerequisites, or post-conditions. The schema covers parameters but not behavioral context, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all parameters are fully described in the schema (chatId, member with role and userId, visibleHistoryStartDateTime). The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action with a verb and resource: 'Add a user to an existing Teams group chat.' This clearly distinguishes it from sibling tools like teams_add_team_member or teams_add_channel_member by specifying 'group chat'.
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 phrase 'existing Teams group chat' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it (e.g., for team or channel membership). The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the deletion is a 'soft-delete' and that Microsoft Graph/tenant policy enforce permissions. However, with no annotations, it carries the full burden, and it does not explain reversibility, effect on chat participants, or whether the message is hidden immediately. It adds some behavioral context but leaves significant gaps for a 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: two sentences plus Chinese intent mappings. It front-loads the core action and adds one sentence about policy enforcement. Every part adds value; no redundancy or excessive 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?
For a simple 2-parameter, no-output-schema tool, the description covers the essential purpose and adds contextual information about authorization. It could mention the result of the operation (e.g., success state) but 'soft-delete' implies the message is removed from view. Overall it is sufficiently complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both chatId and messageId have descriptions). The tool description does not add any extra semantics about the parameters; it only refers to 'a Teams chat message' generically. Baseline 3 is appropriate since the schema already provides full parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Soft-delete a Teams chat message.' This clearly distinguishes from sibling tools like teams_delete_channel_message by specifying 'chat message' rather than channel message. It also provides Chinese intent mappings, which reinforces the exact action being described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as teams_delete_channel_message. The Chinese intents are essentially synonyms, not usage guidance. It does not mention exclusions or prerequisites beyond 'tenant policy' but that is not tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the important auth requirement 'Requires delegated Chat.Read', which is beyond the schema. However, it does not disclose other behavioral traits such as default pagination, sorting order, or response structure (e.g., message fields). Since no annotations are provided, the description carries the full burden, but this simple read-only tool provides only minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English portion is concise and front-loaded, stating the purpose and auth requirement in one clear sentence. The Chinese intent list adds redundancy but does not bloat the description. Overall, it is efficient and 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?
Given the tool's simplicity (2 params, no output schema, no annotations), the description covers purpose and auth but lacks details on return format or how the result relates to other chat tools. It also does not explicitly differentiate from teams_list_channel_messages, leaving some ambiguity for the agent. This is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (chatId and top) have descriptive text in the schema (100% coverage), so the tool description does not need to add parameter info. The description itself adds no param-specific guidance beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically states 'List recent messages in a Teams chat', combining a clear verb ('list') with a specific resource ('recent messages in a Teams chat'). This clearly distinguishes it from sibling tools like teams_list_channel_messages, which focus on channel messages rather than chat messages. The additional Chinese intents reinforce the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as teams_list_channel_messages or teams_list_chats. The usage is implied by the tool's name and description, but the description stops short of stating 'use this for Teams chats, not channel messages' or mentioning any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the required delegated permission (User.Read.All), which is useful, but it does not disclose what is returned, error conditions, or behavior when the user has no manager. The description lacks sufficient behavioral detail beyond the permission statement, falling short of full 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 concise and front-loaded with the primary purpose, followed by a permission note and localized Chinese intents. The Chinese intents add value for multilingual support, though they slightly lengthen the text. Overall, it is appropriately sized and clear without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional param, no output schema), and the description covers its core purpose and permission requirement. However, it does not explain what the returned manager data looks like (e.g., ID, displayName), which would be helpful since no output schema exists. This gap prevents it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single optional parameter with a complete description: 'User ID or UPN. Omit to query the signed-in user.' Schema description coverage is 100%, so the description does not need to add parameter details. The baseline of 3 is maintained since the schema handles the semantics and the description does not provide additional value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the manager of the signed-in user or another organization user. The verb 'Get' and resource 'manager' are specific, and it distinguishes itself from sibling tools like users_get_profile and users_list_direct_reports by targeting the manager relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it can be used for the signed-in user or another user, with the param 'Omit to query the signed-in user' in the schema. It also notes the required permission, but does not explicitly mention alternatives or when not to use it. This is a clear context without exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds a key permission requirement (delegated User.ReadBasic.All) and implies read-only behavior, but it does not disclose return format, pagination details, or other behavioral traits like 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 appropriately concise: two English sentences plus a Chinese intents line. It is front-loaded with the core purpose and includes essential permission information without 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?
For a simple list tool with one optional parameter and no output schema, the description covers the core purpose, permission requirement, and language variants. It is reasonably complete, though it could mention that the result is a list or that 'top' controls page size, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter 'top' with 100% coverage, giving the baseline of 3. The description adds no additional parameter semantics, such as default behavior or how to use top.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), resource (organization users), and scope (basic profile fields), which distinguishes it from sibling tools like users_search and users_get_profile. However, it does not explicitly name alternatives, so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear purpose but no explicit guidance on when to use this tool vs alternatives. Usage is implied ('list organization users') and permission requirements are given, but no 'when not to use' or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects. It mentions the required permission but fails to state that this is a write operation that mutates the event, may notify the organizer, or that sendResponse defaults to true. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and includes only essential information: the action, permission, and Chinese equivalents. There is no redundancy or filler, so every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential purpose and permission, while the schema covers parameter details. However, it lacks usage guidelines versus alternatives, omits behavioral consequences (e.g., organizer notification), and there is no output schema or return value information. These gaps make it minimally viable, not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by mapping Chinese intents (接受会议邀请, 拒绝会议邀请, 暂定会议) to the response enum values, aiding interpretation of non-English requests. This goes beyond the schema's plain descriptions and helps with parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 identifies the action (accept, tentatively accept, or decline) on a meeting invitation, making it clear what the tool does. It distinguishes itself from sibling calendar tools like create/update/cancel event by focusing on the 'respond' action, and the addition of Chinese intents further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a required permission (delegated Calendars.ReadWrite) but does not explicitly say when to use this tool versus alternatives. No exclusions or alternative tool references are provided, so usage context is implied by the name and sibling list rather than clearly described.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It notes the required delegated Contacts.Read permission, which is useful, but it does not mention pagination, sorting, or potential errors. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one English sentence with purpose and permission, followed by Chinese intent examples. It is front-loaded and every part adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description lacks explicit clarification about scope (e.g., whether it includes contacts from all folders) and does not differentiate it from contacts_list_folder_contacts. It is adequate but could be more complete given the sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full description for the only parameter 'top' (range 1-100), so baseline is 3. The description does not add extra semantic meaning beyond the schema, which is acceptable given high 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?
The description clearly states the tool's purpose: listing mailbox contacts for the signed-in user. It uses a specific verb ('List'), resource ('mailbox contacts'), and scope ('for the signed-in user'), distinguishing it from folder-specific or search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user wants to see their own contacts, but it does not explicitly provide alternatives or exclusions (e.g., for folder-scoped contacts, use contacts_list_folder_contacts). The permission requirement and multilingual examples give some context, but no direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states that output is base64 and that the MCP response is limited to 10 MB, which is critical for size expectations. However, it does not mention permissions, read-only status, or failure behavior on missing/invalid item IDs, leaving room for more 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 core behavior and the 10 MB limitation are stated in the first two sentences, keeping the most important information front-loaded. The third sentence with Chinese intent alternatives is somewhat extra but serves multilingual intent recognition without being verbose. Overall the description is compact and free of unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter download tool with no output schema, the description explains the return format (base64), the key constraint (10 MB), and the resource type (OneDrive file), which is enough for invocation. It does not cover error handling or large-file alternatives, but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter itemId as 'File item ID', giving 100% schema coverage. The description does not add additional parameter-level meaning or format guidance beyond what the schema already provides. The baseline of 3 is appropriate since the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Download a OneDrive file' – a specific verb and resource – and further clarifies it returns base64 bytes. This distinguishes it from metadata tools like drive_get_item and from sharepoint_download_file by scoping to OneDrive. The added Chinese intent examples reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for downloading file content, but it does not explicitly state when to prefer this tool over siblings like drive_get_item or sharepoint_download_file. It also does not mention exclusions such as files larger than 10 MB being unsuitable. The Chinese intent mapping offers some context but no tool-selection boundary.
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?
With no annotations, the description carries the full burden. It discloses the permission requirement ('Requires delegated Mail.Read') and the scope ('signed-in user mailbox'), which is useful. However, it does not disclose behavioral details like sorting, pagination, or folder scope beyond what the schema already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two primary sentences and a Chinese intent expansion. The main purpose is front-loaded and there is no fluff. The Chinese intents add some length but serve a multilingual intent-matching purpose, so it's not zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and no output schema, the description covers the essential aspects: purpose, permission, and query examples. It could explicitly state that it returns a list of messages, but this is implied by the name and the top parameter. Overall, it is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description does not add any parameter semantics beyond what the schema already explains. The 'by keyword' phrase mirrors the query parameter description, so there is no additional 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 states a specific verb ('Search'), resource ('messages in the signed-in user mailbox'), and method ('by keyword'). This clearly distinguishes it from siblings like mail_list_messages (which lists all messages) and mail_get_message (which retrieves a single message).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user wants to search for emails by keyword, and it notes the permission requirement. However, it does not explicitly mention alternatives or when not to use it, such as preferring search_mail for broader searches or mail_list_messages for listing without a keyword.
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?
With no annotations provided, the description carries the burden. It discloses that output is base64 and that the response is limited to 10 MB, which is useful. However, it does not specify error behavior for files exceeding the limit, authentication requirements, or confirm read-only nature, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two primary sentences plus a localized intent section. The main purpose is front-loaded and the 10 MB limitation is an important caveat presented early. The Chinese intents add slight redundancy but remain compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple download tool with two parameters and no output schema, the description covers the essential purpose, return format, and critical size limitation. It omits explicit differentiation from drive_download_file, but the name and sibling list help. The 10 MB limit is a crucial operational detail that makes it practical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both itemId and driveId have descriptions). The tool description adds no parameter-specific explanation beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download') with a specific resource ('a document-library file') and output format ('as base64'). This distinguishes it from sibling tools like drive_download_file which targets OneDrive files, while the Chinese intent section reinforces the SharePoint 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 downloading SharePoint document library files and notes the 10 MB response limit, which is a key usage constraint. However, it does not explicitly state when to use this tool over drive_download_file or mention any alternatives for files larger than 10 MB.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by noting the required delegated permission and clarifying that document-library lists are included. However, it does not explicitly state that this is a read-only operation or describe what the returned data contains, so transparency is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a permission note and a Chinese intent list. The Chinese intent phrases are somewhat repetitive but serve a localization purpose, so the structure is efficient with only minor 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 simple list operation with no output schema, the description covers the essential aspects: what it lists, the required permission, and the inclusion of document-library lists. It does not mention pagination or return formatting, but these are partially covered by the schema's 'top' parameter, and the operation is straightforward enough that the description feels complete for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with descriptions for both 'siteId' and 'top'. The description adds no additional parameter-specific semantics beyond reinforcing the site scope, so it does not exceed the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') on a specific resource ('SharePoint lists and document-library lists') with a scope ('in a site'), and it distinguishes this from sibling tools such as sharepoint_list_list_items or sharepoint_list_drives by explicitly covering both regular lists and document-library 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 implies when to use the tool (when you need to see lists in a site) and includes a permission prerequisite, but it does not explicitly compare with alternative tools like sharepoint_list_drives or sharepoint_list_list_items, nor does it mention exclusions. This makes usage guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral impact. It only states the action and scope; it does not mention side effects such as broken sharing links, overwrite behavior, permission requirements, or how the item's metadata/version history is affected. For a mutating operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the core action is front-loaded in English, followed by Chinese translations/examples. No wasted words, and the multilingual hint adds utility for Chinese-language intents without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move operation with three required parameters and no output schema, the description covers the basic 'what' and 'where.' However, it lacks behavioral details such as error conditions, required permissions, or return values, and since there are no annotations to compensate, the description is only minimally complete for real-world use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (source item ID, drive ID, destination parent folder ID) with 100% coverage, giving a baseline of 3. The description adds an important semantic constraint that the destination folder must be in the same document library, which helps the agent understand the relationship between parameters and reject invalid destinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 and specific: 'Move a file or folder to another folder in the same document library.' It names the verb (move), object (file/folder), and scope (same document library), which distinguishes it from copy, rename, or delete operations. The Chinese examples reinforce the intended use case.
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 compare against sibling tools like drive_move_item or sharepoint_copy_drive_item. It implies the use case (reorganizing files within a SharePoint library) and includes the constraint 'same document library,' but lacks explicit 'use this when' or exclusion criteria for alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral detail: the required permission 'Sites.Manage.All'. Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does not mention whether unspecified fields remain unchanged, what the response looks like, or any side effects, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core action and resource front-loaded. The Chinese intent line is concise and supports multilingual queries without redundancy. Every sentence adds value, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description provides the essential purpose and permission but omits practical details like return values, effect on existing data, or when to prefer this over sharepoint_update_list_item. It is minimally complete but leaves the agent to infer key behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with 100% description coverage, so the baseline is 3. The description's mention of 'name or description' maps directly to displayName and description but adds no new meaning beyond the schema, such as constraints or behavior when both are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Update') and resource ('name or description of a SharePoint list'), which distinguishes it from item-level operations like sharepoint_update_list_item and from list create/delete tools. Chinese intent aliases further reinforce the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It mentions a required permission (Sites.Manage.All) as a prerequisite, but lacks exclusions or comparisons to related tools such as sharepoint_update_list_item. Usage context is implied by the verb 'Update' but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description to carry the full burden of disclosing behavioral traits. The description states the high-level functions but does not disclose whether the tool modifies calendar data, how it determines working hours, what timezone it uses, or what the output format is. While 'detect' implies read-only, this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using one sentence for the main function and a compact multilingual intent list. It is front-loaded with the core functionality, and every element serves a purpose—including the Chinese intents for multilingual support. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple input schema (one optional parameter) and no output schema, so the description should ideally clarify what the agent can expect in the return value. It does not describe the structure or format of the conflict/free-slot results, leaving some ambiguity. However, the core purpose is clear and the tool is simple enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'days' parameter, which is fully described in the input schema. The description adds no parameter-specific information, so it stays at the baseline score of 3 for high 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?
The description clearly states the tool's function: 'Detect overlapping events and list free working-hour slots.' It uses specific verbs and resource concepts (events, free slots) and distinguishes itself from sibling calendar tools like calendar_get_schedule or calendar_list_events by focusing on conflict detection and free slot discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, especially via the Chinese intents (检查日程冲突, 查找空闲时间, 分析未来日程), which explicitly map to user queries for conflict checking and free time analysis. However, it does not mention exclusions or alternative tools, so it lacks explicit 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the mutating action and the permission prerequisite, but does not mention potential failure modes, side effects, or idempotency. This adds some value beyond the schema, but deeper behavioral details are missing.
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, followed by a useful permission note. The Chinese translation adds extra text but is not unnecessary for localisation. Overall, it is efficiently written.
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 add-member tool with two parameters and one nested object, the description adequately covers the core purpose and a key permission requirement. There is no output schema, but for a mutation action, the lack of return value details is acceptable. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for both teamId and member, covering 100% of parameters. The description's reference to roles aligns with the nested role property but adds little meaning beyond what the schema already documents. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Add), the resource (Microsoft Entra user to a team), and the supported roles (member, owner, guest). This differentiates it from sibling tools like teams_add_channel_member and teams_add_chat_member, which target other membership scopes.
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 required permission (TeamMember.ReadWrite.All) and authority requirement, which is helpful context. However, it does not explicitly state when to use this tool versus alternatives, such as teams_add_channel_member or teams_add_chat_member. The intended use is implied rather than explicit.
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?
With no annotations provided, the description carries the burden of disclosing behavior. It states 'Read,' clearly indicating a read-only operation, and specifies that it returns settings and summary details, which sets expectations about scope. However, it does not disclose prerequisites (e.g., team membership), error behavior, or how to obtain the teamId. This is a minimal level of transparency for a simple get operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, with the main purpose front-loaded. The Chinese intents are somewhat redundant but not harmful, and they may aid multilingual usage. Overall, it is efficient and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool without an output schema, the description covers the essential purpose and return scope ('settings and summary details'). It does not explain the exact fields returned, but this is not expected given the lack of an output schema. It could arguably benefit from a pointer to teams_list_joined_teams for obtaining teamId, but the description is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter (teamId) with a clear description, so the parameter semantics baseline is 3. The description adds no additional meaning beyond the schema; it does not specify the format or any constraints on teamId beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Read settings and summary details for a Microsoft Teams team,' using a specific verb and resource. It clearly distinguishes this from sibling tools like teams_list_joined_teams (list all teams) and teams_get_channel (get a channel). The Chinese intents further reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a single team's settings and summary, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative recommendations are provided. Sibling tools like teams_list_joined_teams could be mentioned for getting team IDs, but the description lacks such 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the core action ('List members and owners') and does not mention pagination behavior, required permissions, whether owners are also included as members, or any response format. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with the main purpose stated first. The Chinese intent phrases are supplementary but do not create bloat. Every part serves a purpose, making it very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and no output schema, the description is adequate in stating the core purpose. However, it does not elaborate on return structure, pagination, or potential access requirements, leaving some gaps for an agent needing full operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters at 100% coverage ('Teams team ID', 'Number of members to return'). The description adds no additional semantic value for the parameters beyond reinforcing the team-level scope, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'List members and owners of a Microsoft Teams team.' This is a specific verb and resource, and it clearly distinguishes the tool from siblings like teams_list_channel_members and teams_list_chat_members by specifying 'of a Microsoft Teams team'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to list team members/owners) but does not explicitly mention exclusions or alternatives. It is clear enough to infer usage, but lacks a direct 'when not to use' statement differentiating it from related membership tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It adds the signed-in user context and required delegated permission, which is helpful. However, it does not explain side effects (e.g., creates a threaded reply), return values, or rate limits beyond the obvious mutation implied by 'Reply.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the core purpose and permission. The Chinese intent line adds multilingual searchability without excessive bloat, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations exist, and the description covers the essential action and permission, but it omits return format, error conditions, and confirmation behavior. The tool is simple enough that this is acceptable, but there is room for a note about successful response or thread behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 5 parameters, so the schema already documents each field. The tool description adds no extra parameter-level context beyond the schema, placing it at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Reply to a Teams channel message as the signed-in user.' It specifies a precise verb (reply) and resource (channel message), distinguishing it from siblings like teams_send_channel_message (send new) and teams_list_channel_message_replies (list replies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the word 'Reply' and the resource type, but the description does not explicitly contrast this with alternatives like teams_send_channel_message or provide when-not-to-use guidance. The permission requirement 'Requires delegated ChannelMessage.Send' adds context but no explicit win/loss criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden of behavioral disclosure. It only states 'update' without mentioning permissions, whether the update is partial or replaces fields, or the expected outcome/response. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded with the primary English sentence. The Chinese intent translations are additional but serve a purpose for intent matching without adding unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 100% schema coverage, the description is minimally adequate. However, it omits details like whether at least one of description/displayName must be provided, return behavior, and update semantics, which are not covered by annotations or an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic parameter descriptions ('New description', 'New channel name'), so the baseline is 3. The tool description does not add meaningful semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update the name or description') on a specific resource ('a Microsoft Teams channel'), distinguishing it from sibling tools like create, delete, or get channels. The included Chinese intent examples further reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for modifying an existing channel's name or description, which provides clear context. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to know when to select this tool over sibling channel tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a read operation and requires delegated Calendars.Read permission, which is valuable. However, it provides no detail on error behavior, response contents, or other side effects, which is a gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two sentences plus Chinese examples, with every piece earning its place. It conveys purpose, permission, and language support without 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?
For a simple single-parameter read tool, the description provides good coverage: purpose, permission, and Chinese alternatives. It lacks a pointer to how to obtain the eventId (e.g., via calendar_list_events) and what 'details' includes, but the absence of an output schema reduces the need. Overall, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of the single parameter (eventId described as 'Calendar event ID'). The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read details for a calendar event' with a specific verb and resource. This distinguishes it from sibling tools like calendar_list_events (listing) and calendar_update_event (modifying). The Chinese intents further reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese intents give examples of when to use it (view meeting details, read event), and the permission requirement is stated. However, it does not explicitly contrast with alternatives such as calendar_list_events or calendar_get_schedule, nor does it state when not to use it. This leaves usage guidance mostly implied.
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?
With no annotations, the description carries the full burden. It usefully discloses the delegated Files.ReadWrite permission and target location, but it omits behavior around name conflicts (despite the schema enum), return values, and error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is concise and front-loaded with the action and target. The Chinese intent line adds a bit of length but serves a clear multilingual purpose. No redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with a well-described schema, the description is serviceable. However, without an output schema, it does not mention return object shape, and it lacks explicit sibling differentiation or conflict-behavior caveats, leaving moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the baseline is 3. The description adds context about root/parent location that maps to parentItemId, but it does not add significant syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('folder in the signed-in user OneDrive root or under a parent folder'), clearly distinguishing it from sibling tools like mail_create_folder, contacts_create_folder, and sharepoint_create_drive_folder by scope.
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 clearly states the intended context (signed-in user's OneDrive, root or parent folder) and the required permission. However, it does not explicitly mention when not to use it or contrast with sharepoint_create_drive_folder, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the required delegated Files.ReadWrite permission, which is useful context. However, it does not describe behavioral expectations such as what happens on conflicts, whether the rename is reversible, or what the response contains. With no annotations, this leaves some gaps, but the tool's core behavior is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action and resource. The Chinese intent line is purposeful for supporting Chinese queries and does not bloat the description unnecessarily. Every part serves a function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description adequately covers purpose, scope, and permission. It would be slightly more complete if it mentioned the response format or error behavior, but given the low complexity, the current content is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both itemId and newName, so the schema already covers parameter semantics. The description adds no additional parameter details beyond what is in the schema, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Rename' and the resource 'file or folder in the signed-in user OneDrive'. It is specific and distinguishes from sibling tools like drive_move_item and sharepoint_rename_drive_item by indicating the OneDrive scope. The Chinese intent clarifies the purpose further for multilingual use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying the signed-in user's OneDrive and the required permission, but it does not explicitly mention when to use this tool versus alternatives such as sharepoint_rename_drive_item. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: 'including transitive membership' and 'up to 20 supplied group IDs.' However, it does not disclose the return format (e.g., list of matching group IDs vs. boolean per ID), error handling for invalid IDs, or authentication expectations. The description gives basic behavioral traits but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the core statement and a multilingual repetition. Every sentence serves a purpose, with no unnecessary fluff. The main information is front-loaded: 'Check which of up to 20 supplied group IDs contain the signed-in user, including transitive membership.'
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 (one parameter, no output schema), the description covers the key aspects: the action, the parameter scope, and the transitive membership behavior. It does not explicitly state the return value structure, but the phrase 'Check which... contain' implies the output will be the subset of supplied group IDs where the user is a member. This is reasonably 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for groupIds ('Group IDs to check.') is clear, and schema coverage is 100%. The tool description adds context about checking against the signed-in user and the limit of 20, but these are already present in the schema or are not additional semantics about the parameter's format or usage. Thus, the description provides minimal extra 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 a specific action: 'Check which of up to 20 supplied group IDs contain the signed-in user, including transitive membership.' This distinguishes it from sibling tools like groups_list_members (which lists members of a group) and users_list_memberships (which lists all memberships) by focusing on checking a supplied set of group IDs against the current user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you have a set of group IDs and need to check if the signed-in user is a member, especially with transitive membership. However, it does not explicitly mention when to use this tool instead of alternatives like users_list_memberships or groups_list_members, nor does it state exclusions. Thus, the usage guidance is only implied.
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?
With no annotations, the description carries the full burden. It discloses the 'direct members' scope and the additional tenant permissions for hidden-membership groups, which is useful. However, it does not mention return format, pagination, or default behavior when 'top' is omitted, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: the core action, a permissions caveat, and Chinese intent variants. Every sentence earns its place with no fluff, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 100% schema coverage and no output schema, the description is nearly complete. It covers the core behavior and an important permission nuance. It could benefit from a brief note on the return shape, but that is not critical given the schema and tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (groupId, top) have clear descriptions. The tool description adds no extra parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List direct members of a group' – a specific verb and resource. The term 'direct members' differentiates from sibling tools like groups_list_owners and groups_get, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'List direct members of a group' but provides no explicit alternatives or when-not-to-use guidance. The hidden-membership permission caveat adds context, but it doesn't direct users to other group-related tools for different needs.
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?
With no annotations provided, the description carries the full transparency burden. It does disclose the required delegated Mail.ReadWrite permission, which is useful. However, it does not mention the destructive nature of moving (removing from the source folder) or any other side effects, limiting full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action and required permission. The Chinese translations add multilingual value without bloating the content. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter tool, the description covers the core purpose and permission. It does not explain return values or side effects in detail, but the absence of an output schema reduces that need. Overall, it is adequately complete for this action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions. 'Message ID' and 'Destination folder ID from mail_list_folders' already provide meaning. The tool description adds no additional parameter explanations beyond the schema, so it holds to the baseline without enhancing semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move a message to a target mailbox folder' with a specific verb and resource. It distinguishes itself from sibling tools like mail_copy_message and mail_delete_message by the unique move action. The inclusion of Chinese intents reinforces the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like mail_copy_message when duplication is needed, nor does it specify exclusions. The context is clear but lacks direct comparison to sibling operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the need for delegated Mail.ReadWrite permission, which is useful behavioral context. However, it does not mention side effects, reversibility, error scenarios, or the response format. For a rename operation, this is adequate but not rich.
Agents need to know what a tool does to the world before 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 one clear English sentence and a brief permission note. The Chinese intents are compact and provide localization value without bloat. Every element 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 tool's simplicity (2 params, no nested objects, no output schema), the description covers the essential action and permission requirement. It is complete enough for an agent to invoke correctly. The schema fully documents parameters, so no additional parameter context is needed. It lacks return value details, but this is not critical for a simple rename.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (folderId and displayName). The description adds little beyond the schema, only implying that folderId is the target and displayName is the new name. Since the schema already documents these, the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Rename a mailbox folder' with a specific verb and resource. This unambiguously distinguishes it from sibling tools like mail_create_folder, mail_delete_folder, and mail_list_folders. The title reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to rename a mailbox folder) but does not explicitly provide when-to-use vs alternatives or exclusions. The permission requirement is a prerequisite rather than a usage guideline. No alternatives or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the burden. It clearly states the access-granting action and target, but does not disclose side effects such as invitation emails, sign-in requirements, or whether existing permissions are overwritten. This leaves some behavioral ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one English sentence plus Chinese equivalents. It front-loads the key action and resource without any fluff, making 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?
For an action tool with a rich schema and no output schema, the description provides the essential context. However, it lacks a mention of how permissions are applied (e.g., role mapping) and does not reference the optional parameters that affect behavior, leaving some completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 is appropriate. The description adds minimal semantic value beyond the schema by referencing 'selected people' (recipients) and 'read or write' (roles), but does not elaborate on parameter formats or behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Grant') and clearly identifies the resource ('SharePoint file or folder') and the access levels ('read or write'). This distinguishes it from generic drive tools by explicitly mentioning SharePoint, and the Chinese intents reinforce the intended use case.
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 explain when to use this tool versus alternatives like drive_invite_item or share links. It only provides context that it works with SharePoint items, which is implied by the name. No exclusions or alternative tool references 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?
No annotations are present, so the description carries the full burden. It adds a useful permission requirement and scopes the search to a document library. Yet it does not disclose behavior around pagination, whether content or metadata is searched, or return characteristics, leaving notable gaps for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The Chinese intent mapping adds localization value relevant to potential users, though it is somewhat redundant. Overall, it is brief and structured without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameters and the description covers scope and permission, which is adequate for a simple search tool. However, with no output schema, it does not describe return values or pagination behavior, and it does not differentiate from sibling search tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for all three parameters (driveId, query, top), with 100% schema description coverage. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search files and folders in a SharePoint document library', giving a specific action (search) and resource (SharePoint document library). This distinguishes it from sibling tools like sharepoint_search_sites (site-level search) and sharepoint_list_drive_items (listing without keyword 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?
It provides clear context—searching in a SharePoint library—and includes a meaningful prerequisite ('Requires delegated Files.Read.All'). However, it does not explicitly contrast with similar tools like drive_search_items or sharepoint_search_sites, so it lacks explicit when/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain behavioral traits. It discloses the soft-delete behavior and permission enforcement, which adds context. However, it does not mention side effects on replies, reversibility, or error outcomes, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and effectively front-loaded: the core purpose is stated first, followed by a permission note and a Chinese intent line. Every sentence earns its place 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 straightforward delete operation, the description plus schema adequately capture the core information: what is deleted, the permission context, and the parameters. No output schema exists, but the tool likely returns a simple success/failure; a bit more on consequences or return values would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter descriptions, so the schema already covers parameter meanings. The description adds minimal value beyond the schema, merely repeating that messages or replies can be deleted without explaining the replyId logic further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 action: 'Soft-delete a Teams channel message or reply.' This distinguishes it from sibling tools like teams_delete_chat_message and teams_delete_channel, and explicitly covers both root messages and replies.
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 intended use case is implied by the tool name and resource, but the description gives no explicit guidance on when to use this tool over alternatives like teams_delete_chat_message. The note about Microsoft Graph and tenant policy is a constraint, not a usage guideline.
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?
There are no annotations provided, so the description carries the full burden for behavioral context. It discloses a key trait: requiring delegated ChannelMessage.Read.All and usually tenant admin consent. However, it does not describe anticipated output format, pagination behavior, or any side effects beyond being a read operation, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences (plus Chinese intent translations) that directly state the tool's purpose and a permission caveat. It is front-loaded with the core action and contains no wasted words, earning a high score.
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?
This is a straightforward read-only list operation without an output schema. The description covers the essential action and permission requirements, and the schema fully documents the parameters. It could be slightly more complete by mentioning whether the result is a flat list or supports pagination via the 'top' parameter, but given the simplicity of the tool and the schema coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all four parameters, including semantics for teamId, channelId, messageId, and top. The description does not add additional meaning to these parameters beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List replies under a Teams channel message' with a specific verb and resource. It distinguishes this tool from siblings like teams_list_channel_messages, which lists messages in a channel rather than replies to a specific message. The inclusion of Chinese intent phrases further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear purpose but does not explicitly guide when to use this tool versus alternatives. It mentions permission requirements (delegated ChannelMessage.Read.All and tenant admin consent) which implies a prerequisite but does not contrast with other sibling tools such as teams_list_channel_messages or teams_send_channel_message. Use is implied by the resource type, but no direct alternatives or exclusions are stated.
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?
With no annotations provided, the description carries the transparency burden. It explicitly says 'Read' indicating a read-only operation and includes an authorization requirement, which is useful. It does not cover edge cases like invalid IDs, but for a simple read operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and immediately followed by the permission requirement and helpful Chinese intents. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-user get operation with one parameter and no output schema, the description is fairly complete. It states the fields included in the profile, which gives an agent a good sense of the return value, and it notes the required permission. It could elaborate on error behavior, but this is not critical for a basic fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter (userIdOrPrincipalName) with a clear description. The tool description adds no extra parameter-level details beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a tenant user profile and lists content fields (job title, department, contact fields). It is distinguishable from siblings like users_list or users_search by focusing on a single profile, but it does not explicitly contrast with these alternatives.
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 required permission (delegated User.Read.All) and provides Chinese intent examples, which imply usage scenarios. However, it does not explicitly say when to use this tool over users_get_manager, users_list, or users_search, leaving the usage guidance somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the permission requirement and default calendar scope, but doesn't mention side effects such as invitation sending to attendees, online meeting creation behavior, or return value. This is a gap for a write tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the primary action and permission requirement. The Chinese intents add multilingual value without unnecessary bulk, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with nested start/end objects, optional attendees, and an online meeting flag. With no output schema or annotations, the description could disclose more about return behavior and side effects, but it's reasonably scoped for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions (e.g., dateTime format, timeZone default, attendee type enum), so the description adds no extra parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (create) and resource (event/meeting in the signed-in user's default calendar), clearly distinguishing it from sibling calendar tools like update, cancel, or delete. It also states the required permission, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the tool creates an event/meeting in the default calendar and requires delegated Calendars.ReadWrite, providing a clear context for invocation. It doesn't explicitly mention alternatives, but the action is self-evident compared to other calendar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a permission requirement ('requires delegated Calendars.Read') and a regional support constraint ('Supported in 21V'), which is valuable. However, it does not describe the return format, behavior when no availability exists, or any error conditions, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences cover the core function and constraints, followed by concise Chinese intent examples. Every sentence adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, nested objects, and no output schema, the description provides a decent overview but fails to mention the response shape or edge cases such as empty requests. It is adequate for a read-only query tool but not fully complete without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra context by mentioning 'users, rooms, or distribution lists' which maps to the 'schedules' parameter, and 'time range' aligning with start/end, but it does not provide deeper semantics than the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get free/busy availability for users, rooms, or distribution lists in a time range' with a specific verb and resource, clearly distinguishing it from sibling calendar tools like list_events or list_view. It also provides Chinese intent phrases, reinforcing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear use cases (checking availability for coworkers/rooms, finding common free time) but does not explicitly exclude alternatives or name when to prefer this over calendar_list_events. It implies usage context well but lacks explicit 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. The phrase 'attachment metadata' explicitly indicates that actual file content is not retrieved, and 'List' implies a non-destructive read operation. While it omits details like auth requirements or error behavior, this is a reasonable disclosure for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose. The additional Chinese intents are helpful for multilingual contexts but are somewhat redundant; still, the overall structure is tight and 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?
For a simple tool with one parameter and no output schema, the description adequately conveys the action and output type ('attachment metadata'). It does not detail the metadata fields, but given the low complexity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'eventId' parameter described as 'Event ID'. The tool description adds no extra meaning beyond aligning the parameter with 'calendar event', so it meets the baseline of 3 for high 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?
The description uses a specific verb 'List' and clearly identifies the resource as 'attachment metadata for a calendar event'. This distinguishes it from sibling tools like mail_list_attachments and calendar_add/delete_attachment, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: the tool is used when one wants to see attachment metadata for a calendar event. However, it does not explicitly mention when to use it over alternatives or provide exclusions, relying on the reader to infer from the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it requires delegated Calendars.Read and operates on the signed-in user's data, which is useful context. However, it does not explain default behavior for the optional 'top' parameter, ordering, or what happens if no calendars exist, so it only partially covers 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 front-loaded with the primary action, followed by the permission requirement and multilingual hints. Every sentence serves a purpose, and it avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and permission clearly, but lacks details on default behavior and return format, especially since there is no output schema. The optional 'top' parameter's default value is not explained, leaving some ambiguity for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single 'top' parameter with description, min, max, so schema coverage is 100%. The description adds no additional meaning about the parameter, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List calendars for the signed-in user' with a clear verb and resource, and the title reinforces it. This clearly distinguishes it from sibling tools like calendar_list_events that handle events rather than calendars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: listing the signed-in user's calendars, with a permission requirement. It does not explicitly mention alternatives or when not to use it, but the scope is unambiguous, earning a 4 rather than a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds useful context by mentioning 'Requires delegated Calendars.Read' and clarifies scope to 'the signed-in user.' However, it doesn't disclose response format, sorting, pagination, or how 'upcoming' is determined (beyond what schema params imply).
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 main action. It includes usage, permission, and multilingual hints in a compact format. The Chinese intent list adds some length but is useful for multilingual contexts and doesn't detract significantly.
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 list tool with two well-documented parameters and no output schema, the description covers key aspects: scope, usage, permissions, and intent. It is not missing critical information for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (top, daysAhead) have clear descriptions. The tool description does not add additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List upcoming calendar events for the signed-in user' with a specific verb and resource. It distinguishes itself from sibling tools like calendar_list_calendars (list calendars) and calendar_get_event (single event) by focusing on upcoming events for the signed-in user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use for today, this week, or upcoming meeting queries.' This gives clear context for when to invoke the tool. It doesn't explicitly name alternatives but the usage context is sufficient for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral trait: the copy is asynchronous and may return an operation monitor URL. Since no annotations are provided, this partially fulfills the transparency burden. However, it omits details about permissions, error handling, and whether the copy preserves 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 concise and front-loaded with the core purpose. The Chinese intent lines are redundant for an English-only workflow but do not significantly bloat the description. One extra sentence could be trimmed, but overall it is 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?
For a moderately simple asynchronous copy tool, the description covers the primary behavior (async, monitor URL) and all parameters are fully documented in the schema. It could add caveats about long-running operations or failure modes, but it is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with descriptions at 100% coverage, so the baseline is 3. The description does not add alternative meanings or nuances; it only restates the target folder concept in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 action ('Copy'), the resource ('OneDrive file or folder'), and the destination ('to another folder'). It also notes asynchronous execution, which distinguishes it from synchronous copy tools and from sibling tools like move or rename. The Chinese intents reinforce the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when duplicating an item to another folder. It does not explicitly mention alternatives or exclusions, but the copy vs. move distinction is implicit via the verb and the sibling tool names (drive_move_item).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the required permission and that 'actual sharing scope depends on tenant policy.' However, it does not mention what the response contains (e.g., the share link URL), side effects, or any limitations beyond permission. Given the lack of annotations, this is partial disclosure but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences in total. The first two sentences are information-dense, and the third provides Chinese intent mappings, which may be useful for multilingual agents though not strictly necessary. It is efficient and front-loaded with the primary 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?
The tool has only three parameters, one required, and no output schema. The description covers the main use case, required permission, and a behavioral caveat. It does not describe the return value, but for a straightforward action like creating a share link, the key context is present. The Chinese intent line adds value for intent detection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds no specific parameter-level detail beyond the schema, and the mention of 'file or folder' only loosely corresponds to itemId. No additional meaning is provided for type or scope enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Create a sharing link for a file or folder in the signed-in user OneDrive.' This distinguishes it from related siblings like drive_invite_item (which sends invitations) and sharepoint_create_share_link (which operates on SharePoint).
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 provides clear context by limiting scope to the 'signed-in user OneDrive' and notes the permission requirement (delegated Files.ReadWrite) and tenant policy dependency. However, it does not explicitly name alternatives or state when not to use this tool versus the similar sharepoint_create_share_link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the permission requirement, which is useful, but does not clarify whether deletion is permanent or goes to recycle bin, or any side effects on folder contents. This is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The additional Chinese intent phrases add localization value but are not essential for the core understanding, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description covers the core purpose, scope (OneDrive), and permission. It falls short of explaining permanence or error behavior, but these are less critical for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the itemId parameter fully with a description 'OneDrive item ID.' The tool description does not add further meaning to the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the resource (file or folder in the signed-in user OneDrive). It also distinguishes from sibling tools like sharepoint_delete_drive_item by specifying OneDrive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it's for the signed-in user's OneDrive, and it mentions the required delegated permissions (Files.ReadWrite). However, it does not explicitly state when not to use it or name alternatives (e.g., sharepoint_delete_drive_item), so it lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add useful context by specifying that results are scoped to the signed-in user and filtered by recency. However, it does not disclose limitations such as whether only metadata is returned, how 'recent' is defined, or that this is a read-only operation beyond the verb 'List.'
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 primary sentence is a crisp, front-loaded definition of the tool's purpose. The Chinese intent variants add multilingual guidance without significant bloat, keeping the overall description compact and 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?
For a single-parameter, read-only list tool, the description covers the essential semantics: resource, scope, and recency. With no output schema, it would be slightly stronger to describe the returned item shape, but the low complexity makes the current text reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, `top`, is fully documented in the schema with the description 'Number of recent items to return,' providing 100% schema coverage. The tool description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the specific verb 'List,' identifies the resource as 'files,' and clearly scopes it to 'recently used by the signed-in user,' which matches the title. This distinguishes it from related tools like drive_list_root, drive_list_children, and drive_search_items.
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 phrase 'recently used by the signed-in user' provides a clear retrieval context, making it apparent when this tool should be selected. It does not explicitly mention alternatives or exclusion cases, but the context is unambiguous and sufficient for a simple list operation.
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?
With no annotations, the description carries the full transparency burden. It states the action ('List retained versions') but does not disclose additional behaviors such as read-only nature, permission requirements, pagination, or response format. The description adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before 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 clear sentence plus a useful Chinese intent translation. Both sentences add value; there is no wordiness or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the absence of an output schema and annotations means the description should hint at return values or related tools. It does not explain what the list contains or how it connects to drive_restore_version, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter (itemId) with a description. The tool description does not add any further explanation about the parameter, so it provides no additional 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 states a specific verb+resource: 'List retained versions of a OneDrive file.' This clearly distinguishes it from the sibling tool sharepoint_list_drive_versions, which is for SharePoint. The included Chinese intents further clarify the tool's scope.
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 usage for OneDrive files, which differentiates it from the SharePoint counterpart. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it lacks full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the required delegated Files.Read permission and the user scope (files visible to the signed-in user), which is useful. However, it does not clarify whether the search covers file content or just names, nor does it mention pagination or result format. This is somewhat thin for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two short sentences, with the first conveying the core purpose and the second providing multilingual support hints. No wasted words, and the structure front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), and the description covers permission, user scope, and language support. However, it omits behavior around result ordering, whether full-text search is supported, and any error scenarios. Given the low complexity, this is adequate but not rich; a 3 reflects that the description does not fully stand alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is 100%, so the baseline is 3. The description adds a note about Chinese intents and '按文件名搜索' (search by filename), but this largely echoes the schema's phrase 'file name or document keyword.' It provides minimal additional 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 states the tool's function with a specific verb ('Search') and a clearly defined resource ('files visible to the signed-in user in OneDrive'). It implicitly distinguishes from siblings like sharepoint_search_drive_items and search_files by scoping to the user's own OneDrive. The permission requirement adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: searching the signed-in user's own OneDrive files. It implies a distinction from SharePoint or general file searches, but does not explicitly name alternatives or state when not to use it. Since context is clear but exclusions/alternatives are not explicitly stated, a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the required permission (delegated Mail.ReadWrite) and the draft-only scope, but it does not mention irreversibility, error handling, or what happens on success. This is partial but not comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single action sentence, a permission note, and a Chinese translation. Every sentence serves a purpose, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema fully documents its two parameters. However, with no output schema and no annotations, the description does not specify return values, error behavior, or the permanence of deletion. It is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with clear descriptions ('Draft message ID' and 'Attachment ID to delete'), giving 100% coverage. The description adds no parameter-specific detail beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Delete an attachment from a draft message.' This distinguishes it from sibling tools like mail_list_attachments, mail_get_attachment, and mail_add_file_attachment, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying 'from a draft message,' indicating this tool is only for drafts. However, it does not explicitly mention when not to use it or name alternatives, so it stops short of a full 5.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. It states the destructive nature ('Delete a mailbox folder and its contents') and the required permission, but it does not mention whether the deletion is permanent, if it affects child folders beyond contents, or any recovery options. This leaves important behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. It includes the essential requirement in a second sentence and adds Chinese intents for multilingual recognition. Every sentence serves a purpose, and the length is appropriate for a simple delete tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with no annotations or output schema, the description covers the basic function and permission requirement. However, it omits critical context such as whether the deletion is irreversible or if it includes subfolders. This gap is significant for a destructive operation and prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter folderId with description 'Folder ID to delete.' The tool description does not add any parameter-specific meaning beyond the schema. With high schema coverage, the baseline is 3, and no additional semantic contribution is made.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 with a specific verb and resource: 'Delete a mailbox folder and its contents.' This distinguishes it from sibling tools like mail_delete_message (deletes a message) and mail_update_folder (updates a folder). The inclusion of Chinese intents further clarifies the intended 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 a clear usage prerequisite: 'Requires delegated Mail.ReadWrite.' This gives context on when the tool is accessible. However, it does not explicitly mention when to use this tool over alternatives (e.g., mail_delete_message) or any exclusions. The context is sufficiently clear for a well-scoped delete operation.
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?
No annotations are provided, but the description compensates with key behavioral details: raw=true returns base64 bytes, a 10MB limit, and a delegated Mail.Read permission requirement. It does not explain the default (raw=false) return format, which is a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a Chinese intent list, immediately stating the core purpose. Every sentence adds value—usage, size limit, permission, and multilingual support—with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential operation, size limit, and permission, but lacks an output schema and does not clarify the default return format or how to obtain attachmentId from mail_list_attachments. This leaves the tool incomplete for an agent to fully anticipate results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description reinforces raw=true base64 behavior and adds the 10MB limit, but adds nothing beyond the schema for messageId/attachmentId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Read one mail attachment,' which is a specific verb (read) and resource (mail attachment), and it distinguishes from sibling mail_list_attachments by focusing on a single attachment's content. The inclusion of 'one' clarifies 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 fetching attachment content but does not explicitly contrast with alternatives like mail_list_attachments (listing) or mail_get_message (message). No when-not-to-use or alternative tool is named, so guidance is only implicit.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context by noting a required permission ('delegated Mail.Read') and clarifying the user scope. The 'List' verb implies a read-only operation, which is helpful, though it does not mention pagination or return 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?
The main description is concise and front-loaded with the core action and resource. The Chinese intent section adds length but serves multilingual users, and the permission note is useful. Overall it is efficient 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?
For a simple list tool with no output schema and a single optional parameter, the description covers purpose, a use case, and a permission requirement. However, it does not clarify the hierarchy (top-level vs. all folders) relative to sibling tools, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides complete descriptions for the single parameter 'top' (coverage 100%). The description adds no parameter-specific details, so the baseline of 3 is appropriate; the schema carries the weight here.
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 a specific action ('List mailbox folders') with a defined resource scope ('for the signed-in user'). It is distinct from siblings like 'mail_list_child_folders' by implying top-level folders, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage scenario: 'Use this to choose a destination when moving messages.' This helps the agent understand a primary use case, but it lacks explicit guidance on when not to use it or 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?
With no annotations provided, the description carries the full burden. It discloses the required permission (delegated Mail.Read) and the scope (signed-in user mailbox), but does not specify return format, pagination, or explicitly confirm read-only behavior. The term 'recent' is vague.
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 three short sentences covering purpose, capabilities, and permissions. The Chinese intent list adds length but is useful for multilingual support. No unnecessary fluff is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two well-documented parameters, the description provides adequate context: what it does, query options, and permissions. It lacks an explicit return-value description, but 'list messages' implies a list. The ambiguity of 'recent' is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (top and unreadOnly), achieving 100% coverage. The description adds minimal value by mapping 'recent' to top and 'unread' to unreadOnly, but this is not beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 recent messages from the signed-in user's mailbox, using a specific verb and resource. It distinguishes itself from sibling tools like mail_list_folder_messages (folder-specific) and mail_search_messages (search-based) by emphasizing recent/unread queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions supporting recent mail and unread mail queries, giving clear context on when to use the tool. However, it does not mention alternatives or exclusions, such as pointing users to search for keyword queries or folder listing for specific folders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the auth requirements and hints at cross-folder search via the Chinese intent '跨文件夹搜索邮件'. It does not mention return format, pagination, or side effects, but for a read-only search tool, the provided info is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus a concise list of Chinese intent examples. It is front-loaded with the core action and includes no redundant fluff. Every sentence 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?
For a simple search tool with three parameters and no output schema, the description covers the core purpose, syntax, auth, and some usage examples. Gaps include absence of pagination guidance or result format expectations, but overall it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all three parameters, providing baseline 3. The description adds value beyond the schema by clarifying the query uses Microsoft Search syntax and supports cross-folder search, giving agents better context for constructing the query 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 states 'Search mailbox messages with Microsoft Search query syntax,' which is a specific verb and resource. It clearly identifies the tool as a mail search operation and differentiates it from other search tools via the explicit query syntax mention.
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 prerequisite roles ('Requires both mcp.search and mcp.mail roles') and gives Chinese intent examples that imply usage scenarios. However, it does not explicitly compare with siblings like mail_search_messages or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the permission requirement and the allowed creation locations (root or parent folder). However, it does not mention conflict behavior (which defaults to rename) or failure semantics, leaving some behavioral aspects undocumented.
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 core purpose, followed by a useful permission note. The Chinese translation duplicates the first sentence but serves localization needs. Overall, it is compact with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 parameters, no output schema), the description provides the essential action, permission, and scope. It does not explain return values, but that is not required when no output schema exists. Combining with the schema gives sufficient information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptive text for all four parameters (100% coverage), so the baseline is 3. The description adds no substantial parameter meaning beyond the schema; the mention of 'root or parent folder' is redundant with parentItemId's already-documented 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 uses a specific verb ('Create') and resource ('SharePoint document library'), and further scopes it to 'root or parent folder'. This clearly differentiates from sibling tools like drive_create_folder (which targets OneDrive) and sharepoint_create_list_item (which creates list items).
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 by stating the operation is for SharePoint document libraries and includes a required permission (delegated Files.ReadWrite.All). It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait (required delegated permission scope) and a critical invocation detail (internal column names), which adds useful context. However, it does not describe side effects, return behavior, or failure conditions, leaving some gaps for an agent to infer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the core purpose front-loaded in the first sentence. The Chinese intent sentence adds length without new semantic content for English-speaking agents, but it is not overly verbose and does not distract from the core message. Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (3 params, one nested object), and the schema fully documents parameters. The description adds essential context by stating the required permission and the internal-name convention. It does not explain the return value, but given the operation's straightforward nature, this is a minor gap. Overall, the description is sufficient for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of 'internal column names' reinforces the schema's own description for the 'fields' parameter but adds no new information. SiteId and listId are self-explanatory in the schema, so the description does not materially enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb+resource ('Create an item in a SharePoint list') and adds a crucial usage nuance ('using internal column names'), which clearly distinguishes it from sibling tools like sharepoint_update_list_item and sharepoint_delete_list_item. The Chinese intent section reinforces the purpose for multilingual matching.
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 a clear prerequisite ('Requires delegated Sites.ReadWrite.All') which implies when this tool can be used from an authorization standpoint. It gives context on how to invoke it ('using internal column names') but does not explicitly mention alternatives or when not to use it, though the 'Create' verb sufficiently separates it from update/delete 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?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states this is a write operation, that the item may be moved to the site recycle bin, and that delegated Sites.ReadWrite.All is required. This provides valuable context about side effects and permissions beyond the raw schema, though it does not cover every edge case.
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 primary action. It includes useful context about permissions and side effects. The Chinese intent line adds length but serves a purpose for multilingual intent matching. Overall it is appropriately sized, though the Chinese portion could be considered optional for a core agent.
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 simple delete operation, the description covers the core aspects: what it does, that it may recycle, and required permission. It does not explain the return value or behavior when the item doesn't exist, but for a straightforward delete tool with no output schema, this is reasonably complete. The lack of annotations raises the bar, and the description meets it 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?
The input schema has 100% parameter description coverage, with each of the three parameters (siteId, listId, itemId) clearly described. The tool description adds no additional parameter-specific meaning beyond what the schema already provides. Per the baseline rule for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Delete an item from a SharePoint list') with a distinct resource (list item). This distinguishes it from sibling tools like sharepoint_delete_list and sharepoint_delete_drive_item. The title and description are aligned and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context (it is for list items, not lists or drives) and notes that it is a write operation. However, it does not explicitly mention when to use this tool versus an alternative, nor does it provide any 'do not use' guidance. The appropriate usage is implied by the resource name rather than explicitly stated.
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?
With no annotations provided, the description carries the full burden. It discloses the read-only nature and required permission, but does not describe potential errors, rate limits, or what specific metadata is returned. This is minimal but adequate for a simple get operation.
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 essential action and permission in the first two sentences. The Chinese intents add length but serve a purpose for multilingual intent matching. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description provides sufficient context about what the tool does and its prerequisite. It could mention what 'site metadata' includes, but the absence is not a major gap given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so the schema already defines siteId. The description adds 'by site ID' but no additional semantic detail beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read SharePoint site metadata by site ID' with a specific verb and resource, and explicitly scopes it by site ID, distinguishing it from siblings like sharepoint_get_site_by_path and sharepoint_search_sites.
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 provides clear context that the tool operates by site ID and requires the delegated Sites.Read.All permission. However, it does not explicitly state when not to use it or mention alternatives like sharepoint_get_site_by_path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds valuable behavioral information by stating the tool returns 'nextLink or deltaLink state', implying pagination and delta continuation support. However, it does not disclose details such as whether deleted items include metadata, how tokens should be handled, or any authentication requirements, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the core purpose and include useful Chinese translations for bilingual support. Every sentence adds value without unnecessary repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description provides a reasonable high-level overview but lacks critical details such as the response format, how to initiate a fresh delta link, and how to use returned tokens for pagination. This is a moderately complex delta operation, and the description could better explain the token lifecycle and item response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all four parameters, so the baseline is 3. The description does not add additional meaning beyond the schema; it mentions nextLink/deltaLink state but does not elaborate on how the 'token' parameter works, which the schema already partially covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read newly created, updated, or deleted SharePoint list items' with a specific verb and resource, and distinguishes itself from sibling tools like sharepoint_list_list_items by focusing on changes and delta state. The mention of returning 'nextLink or deltaLink state' further clarifies its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates when to use this tool by indicating it handles changes (newly created, updated, deleted) and includes Chinese intents '增量同步清单' (incremental sync) and '获取列表Delta' (get list delta), which imply synchronization scenarios. It does not explicitly state when not to use it or name alternatives, but the context is clear and sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the supported channel types and the 21V limitation for shared channels, but does not mention other behavioral aspects like the need for an owner in private channels (already in schema) or any default behavior beyond what the schema states. The description adds some value but lacks comprehensive 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 two concise sentences plus Chinese intent mappings, front-loading the core purpose first. The Chinese list is slightly redundant for English agents but serves intent matching without bloating the text. Overall, every sentence earns its place, though the structure could be slightly tighter without the language hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 5 parameters and no output schema, the combination of a clear description and a detailed 100% coverage schema is reasonably complete. The description covers purpose and constraints; the schema covers all parameters. It does not describe the return value, but that nuance is secondary for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-specific detail beyond restating 'standard or private', which is already captured by the membershipType enum. It does not clarify any parameter subtleties not already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb ('Create'), an explicit resource ('Teams channel'), and scope ('standard or private'), and explicitly excludes shared-channel creation, distinguishing it from sibling tools like teams_create_chat or teams_update_channel. The Chinese intent list further clarifies the operation's 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?
Provides an explicit when-not-to-use exception: shared-channel creation is excluded because Microsoft does not support it in 21V, giving clear guidance on a specific limitation. However, it does not explicitly name alternative tools for related operations (e.g., teams_update_channel for modifications), so guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. It discloses the auth requirement ('Requires delegated Chat.Read') and the user scope, which are useful. However, it omits details such as whether pagination defaults apply, the maximum number of chats returned if 'top' is omitted, and any explicit statement that this is a safe read-only operation.
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 main action. The Chinese intent block is ancillary but not harmful, and the overall length is appropriate for a simple list operation. Every sentence except possibly the Chinese translation serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description sufficiently covers the core behavior, scope, and permission requirement. Minor omissions like the default value of 'top' are not critical given the low complexity and strong sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter 'top' with a clear description ('Number of chats to return, from 1 to 50'). The tool description itself adds no additional parameter information, so the baseline score of 3 is appropriate since no extra meaning beyond the schema is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List one-on-one and group Teams chats involving the signed-in user,' using a specific verb and resource. It distinguishes itself from sibling tools like teams_list_joined_teams, which list teams, not chats. The Chinese intents also reinforce the purpose for multilingual contexts.
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 by specifying that it lists chats for the signed-in user and requires delegated Chat.Read. It does not explicitly name alternative tools, but the scope ('one-on-one and group chats') inherently differentiates it from team-list or channel-message sibling tools, giving the agent enough signal to select it appropriately.
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?
With no annotations, the description carries the behavioral burden. It explicitly discloses 'Development only' and that the result is cached locally, which are important behavioral traits. It does not detail the interactive device-code prompt or local cache format, but it provides meaningful transparency beyond a vague verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded: a development-only warning, the core action, and the caching result. The Chinese intent list adds value for multilingual intent matching without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description is largely complete: it states the purpose, context, and side effect. It omits the next step (e.g., use auth_complete_device_login) and what the tool returns, but the sibling list and title make this inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters and already describes the optional scopes override and its default. The description adds no extra parameter semantics, but the baseline of 3 applies because the schema does the heavy lifting sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 a specific action: 'Start a 21V Entra device-code login and cache the result locally.' It names the resource (Entra device-code login), the verb (start), and the side effect (cache locally). This differentiates it from sibling tools like auth_complete_device_login and auth_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context with 'Development only' and implies when to use the tool (when initiating a local device-code login). However, it does not explicitly contrast with or point to related tools, such as auth_complete_device_login for finishing the flow, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries this burden. It adds useful behavioral details: 'Requires delegated Calendars.Read' and expansion of 'single and recurring event instances.' However, it does not disclose pagination behavior, response format, or explicitly confirm there are no side effects beyond the verb 'List.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a clear core statement, a required permission, and a brief Chinese intent list. Every part earns its place, and the Chinese intents add useful multilingual guidance without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only list operation with full schema coverage, the description is sufficiently complete: it states purpose, scope, and permission. The lack of an output schema and absence of explicit return-shape/pagination details create minor gaps, but not enough to significantly hinder an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, including formats and defaults. The tool description adds no parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List single and recurring event instances in an explicit date-time range,' which uses a specific verb, resource, and scope. It clearly distinguishes itself from sibling tools like calendar_list_events or calendar_list_event_instances by emphasizing both recurrence expansion and explicit range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when listing event instances across an explicit date-time range. It also adds an auth prerequisite ('Requires delegated Calendars.Read'). However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the permission requirement and the user scope, which is useful. However, it omits behavior like return value, default folder, or error conditions, leaving some important aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence states the action and permission, and the second provides Chinese intent synonyms. Every part serves a purpose, with 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?
For a simple create operation with all optional parameters, the description covers the core purpose, scope, and permission. It leaves out details like the destination folder and return value, but these are partially inferable from the sibling tool list and the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% property description coverage, so all 8 parameters are already documented. The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a mailbox contact for the signed-in user, using a specific verb and resource. It distinguishes itself from sibling tools like contacts_create_folder and contacts_update, and the Chinese intent mapping reinforces the purpose across languages.
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 by specifying the target (signed-in user) and the required permission (delegated Contacts.ReadWrite), helping an agent decide when to use this tool. However, it does not explicitly mention exclusions or alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the required permission (delegated Contacts.ReadWrite) and scope (signed-in user's mailbox contact), which is helpful. However, it does not mention that deletion is irreversible or describe any side effects, which would strengthen transparency for a 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 and front-loaded: the core action is in the first sentence, the permission requirement in the second, and multilingual intents are appended without clutter. Every sentence adds value and the overall length is appropriate for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no nested objects, no output schema), the description covers the essential context: what is deleted, for whom, and under what permission. It lacks an explicit irreversibility warning, but for a basic delete operation, the provided information is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents contactId with the description 'Contact ID.' (100% coverage), so the baseline is 3. The tool description adds minimal param-specific meaning beyond confirming the contact belongs to the signed-in user's mailbox, which is a slight enhancement but not substantial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 and resource: 'Delete a mailbox contact for the signed-in user.' It also explicitly distinguishes this from sibling tools like contacts_delete_folder by naming 'mailbox contact,' and the included Chinese intents reinforce the intended 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 context: it targets the signed-in user's mailbox contact and requires delegated Contacts.ReadWrite permission. It does not explicitly mention alternatives or when-not-to-use, but the purpose is specific enough that an agent can select it appropriately among siblings like contacts_update or contacts_delete_folder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses the read-only nature and permission requirements, but does not describe the return format, whether folder metadata differs from file metadata, or any error conditions. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences plus an optional Chinese intent helper. It front-loads the primary purpose, includes a key permission detail, and has no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description covers the essential context: what it reads, where (signed-in user OneDrive), and the required permission. It lacks explicit return-value details but 'metadata' implies what is returned, making this sufficient for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter (itemId as 'OneDrive item ID from a list or search result') with 100% coverage. The description text adds no further parameter context, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read metadata') and clearly identifies the resource ('file or folder in the signed-in user OneDrive'). This distinguishes it from sibling tools like drive_download_file (downloads content) and sharepoint_get_drive_item (uses SharePoint instead of OneDrive).
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 the required permission ('delegated Files.Read') and implies a read-only usage context. It does not explicitly mention alternatives or when-not-to-use, but the scope is clear enough for an agent to choose this over download or list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds the important permission requirement (delegated GroupMember.Read.All) and confirms the filtering behavior, but does not disclose return format, pagination, or other potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose, filter option, permission, and localized intents in three sentences. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and strong schema coverage, the description covers purpose, filter, and permissions. It does not explain return fields or pagination, but this is not critical for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with clear descriptions for both top and query. The description adds no additional parameter-specific details beyond restating the filter behavior, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and resource ('Microsoft Entra security groups and Microsoft 365 groups'), clearly distinguishing from sibling tools like groups_list_members or groups_get. It also identifies the optional filter behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (listing groups, optionally filtered by prefix) and related Chinese intents. It does not explicitly name alternatives or edge cases, but the context is clear enough relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the disclosure burden. It adds useful behavioral details like the 3 MB decoded size limit and the permission requirement. However, it does not mention the return value, error conditions, or that the action modifies the draft, which would be expected for a complete behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the core action in the first sentence, permission in the second, and a useful multilingual hint in the third. Every sentence adds value, and the structure is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with no output schema, the description covers the essential constraints (size, target, permission) and gives contextual intent phrases. It could be more complete by stating what the tool returns or what happens on failure, but it is sufficient for understanding the tool's primary function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well documented in the schema. The description's mention of 'base64-encoded file under 3 MB' aligns with the contentBase64 property description, but adds no new meaning beyond what the schema already provides. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' and resource 'base64-encoded file to an existing draft message', clearly distinguishing this from sibling tools like mail_send_draft, mail_list_attachments, and calendar_add_file_attachment. It also provides Chinese intent phrases to aid recognition.
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 clearly states the target context: adding a file to an existing draft message. It mentions the permission requirement (delegated Mail.ReadWrite) which helps agents know when the operation is allowed. However, it does not explicitly list alternatives or exclusions, such as not using this for calendar attachments.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a specific permission requirement (delegated Mail.ReadWrite) and clarifies the scope (top-level or child folder), but it does not disclose potential side effects, return behavior, or any post-creation details, leaving some behavioral aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in the first sentence. The permission note is valuable, and the Chinese intents provide localization without bloating the text. Every part serves a purpose, and there is no redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward creation tool with a simple 3-parameter schema and no output schema, the description provides the essential context: what the tool does, the permission required, and the folder hierarchy capability. It lacks details about return values or error conditions, but the simplicity of the operation and full schema coverage make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (isHidden, displayName, parentFolderId) with 100% coverage, so the description adds no parameter-specific meaning beyond what the schema gives. The 'top-level or child' phrasing loosely maps to parentFolderId being optional, but this is redundant with the schema's 'Optional parent folder ID.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'mailbox folder', and further specifies 'top-level or child', distinguishing it from sibling folder creation tools like contacts_create_folder and drive_create_folder. The additional Chinese intent phrases reinforce the tool's purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by indicating the tool creates mailbox folders and requires delegated Mail.ReadWrite permission, which sets expectations for when to use it. However, it does not explicitly contrast with alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds the auth requirement (Mail.ReadWrite) but does not disclose whether the deletion is permanent or moves to trash, nor any return behavior. This is minimally sufficient but lacks deeper 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 a single sentence plus Chinese intents, extremely concise and front-loaded with the action. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description covers the action, the required permission, and the parameter. It lacks side-effect disclosure but is otherwise complete for the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (messageId), so the description does not need to add parameter details. It also does not add extra semantics beyond the schema's 'Message ID' explanation, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a message, using a specific verb+resource. It distinguishes from sibling mail tools like mail_list_messages, mail_get_message, mail_move_message, and mail_copy_message by specifying the delete action. The Chinese intents further clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required permission (delegated Mail.ReadWrite), which is important context for when to use the tool. It does not explicitly list alternatives or when-not-to-use, but the tool's name and the sibling list make the deletion use case obvious.
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?
With no annotations provided, the description carries the burden of disclosing behavior. It adds the permission requirement ('Requires delegated Mail.Send') which is useful, but it does not disclose other behavioral aspects such as immediate sending, impact on the original message, or error/response behavior. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a multilingual intent list. It front-loads the core purpose, states a key requirement, and adds useful Chinese intent mappings without redundant 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 simple forward action with fully described parameters and no output schema, the description covers the essential purpose, permission requirement, and multilingual variants. It could mention whether the message is sent immediately or if the original remains unchanged, but overall it is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides; it only generically references 'recipients'. No additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Forward') and the target ('an existing message') and specifies 'one or more recipients', making it distinct from sibling tools like mail_send and mail_reply. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (forwarding an existing message) but does not explicitly state when not to use alternatives like mail_reply or mail_send. The inclusion of the permission requirement adds 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?
With no annotations, the description adequately discloses the tool's read-only nature ('Read') and permission requirements ('Requires delegated Mail.Read'). It also hints at unread count behavior via the Chinese intents. It does not describe potential side effects or failure modes, but for a simple read operation, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short sentences. The English sentence conveys the core function and permission, while the Chinese lines add multilingual intent examples without unnecessary fluff. Every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema) and lack of annotations, the description covers the essential aspects: purpose, permission, and unread count context. It could be slightly more specific about what 'folder details' includes, but overall it is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete coverage of the 'folderId' parameter, including a description of well-known names like 'inbox' or 'drafts'. The tool description adds no additional parameter context beyond what the schema defines, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads mailbox-folder details and item counts, using a specific verb ('Read') and resource. It distinguishes itself from sibling tools like mail_list_folders and mail_get_message by focusing on folder metadata and counts rather than listing all folders or retrieving individual messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context through the Chinese intent examples (e.g., '查看邮件文件夹详情', '查看文件夹未读数量'), implying it should be used for viewing folder details and unread counts. However, it does not explicitly mention alternatives or when not to use this tool, leaving some ambiguity relative to similar mail folder tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the load. It discloses the permission requirement and the 'recent' qualifier, which is useful. However, it doesn't detail response structure, error behavior, or limitations, so it's adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a localized intent list, with the core purpose front-loaded. Every element earns its place, including the Chinese examples for multilingual 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?
Given the tool's simplicity, the description covers purpose, permission, and folder scope, while the schema covers parameters. Without an output schema, it could hint at return format, but for a list operation this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the baseline is 3. The description adds no extra meaning beyond the schema, merely referencing 'selected mailbox folder' which corresponds to folderId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'List recent messages in a selected mailbox folder', which clearly specifies the verb (list), resource (messages), and scope (selected mailbox folder). This distinguishes it from sibling tools like mail_list_messages (likely inbox-wide) and mail_search_messages (search-based).
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 (selected folder) and a prerequisite (delegated Mail.Read), indicating when it applies. However, it lacks explicit mention of alternatives or exclusions, so it doesn't fully meet the 'when/when-not' bar.
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?
With no annotations, the description carries the transparency burden. It discloses the permission requirement (delegated Mail.Send), which is useful, but it does not mention side effects, whether the reply is sent immediately, or how the comment is used beyond being the reply body.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The Chinese intent list is a helpful addition without bloating the text, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description provides the essential information: what it does and the required permission. It does not need to detail return values, and the absence of an output schema lowers the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers both parameters with descriptions (comment and messageId). The description adds minimal extra meaning beyond the schema, so it meets the baseline for high 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?
The description clearly states the action ('Reply to an existing message') with a specific verb and resource. It distinguishes from sibling tools like mail_send, mail_forward, and mail_create_draft, and the Chinese intent examples reinforce the exact use case.
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 ('existing message') and a key prerequisite ('Requires delegated Mail.Send'). It does not explicitly contrast with alternatives like mail_forward or mail_send, but the wording makes the intended scenario obvious.
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?
There are no annotations, so the description must disclose behavioral traits. It does mention the permission requirement ('delegated Mail.Send'), but it does not describe what happens after sending (e.g., whether the draft is deleted, marked as sent, or if a response is returned). For a mutation tool, this is a moderate disclosure level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence plus a useful bilingual intent list. Every part earns its place, and the core action is front-loaded. There is zero 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?
For a simple one-parameter tool with no output schema and fully covered parameter schema, the description adequately covers purpose and permission. It could mention expected outcome or error behavior, but the simplicity of the operation makes this less critical. The Chinese intents also aid multilingual 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 schema description covers 100% of parameters (messageId with 'Draft message ID.'), so the baseline is 3. The tool description adds no extra detail about the parameter, such as how to obtain or format the messageId. Thus, it provides no added 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 uses a specific verb ('Send') with a clear resource ('an existing draft message'), which precisely identifies the tool's function and distinguishes it from siblings like mail_send (for new messages) and mail_create_draft (for creating drafts). The title 'Send Mail Draft' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing draft message' clearly indicates the tool is for sending drafts, not composing new messages. It also states the required permission ('delegated Mail.Send'), which is a valuable prerequisite. However, it does not explicitly name alternatives or explain when not to use it, so it just misses a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the mutating nature ('mark...read or unread') and the required permission (delegated Mail.ReadWrite), adding meaningful context beyond the schema. However, it does not describe any potential side effects or return behavior, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: two essential sentences plus a useful Chinese intent mapping. Every sentence serves a purpose—function, permission, and multilingual intent—without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core action, permission, and parameters clearly. The absence of an output schema is acceptable for this mutation tool, though a brief note on the response could have added completeness. Overall, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters (messageId and isRead) with clear descriptions, yielding 100% coverage. The tool description adds no additional parameter-level meaning, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Mark a message as read or unread.' This directly distinguishes it from sibling mail tools like mail_move_message or mail_delete_message. The Chinese intent mapping reinforces the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the prerequisite 'Requires delegated Mail.ReadWrite' but does not offer explicit when-to-use guidance or alternatives. There is no mention of when to prefer this over other mail operations, only implied usage from the action described.
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?
With no annotations provided, the description carries the full burden. It reveals the auth requirements (both mcp.search and mcp.drive roles) and the scope (user-visible files). The Chinese phrase '全文搜索' indicates full-text search behavior, which adds meaningful context. It still omits return format or pagination, but the core behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three sentences) and front-loads the main purpose. The Chinese intent examples add some redundancy but also provide useful alternative phrasings for an international audience. Overall, it is efficient, though the Chinese sentence repeats some information from the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the tool returns. It covers scope, permissions, and search modality but does not describe the result structure or how pagination works via from/size. This is a noticeable gap for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (query, from, size) already described in the input schema. The description does not add parameter-specific semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and identifies the exact resource ('files visible to the signed-in user across OneDrive and Microsoft 365'). It clearly distinguishes this from sibling tools like search_mail, search_calendar, and search_teams by specifying the file scope.
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 a clear context: files visible to the signed-in user across OneDrive and Microsoft 365. It also provides a prerequisite (requires both mcp.search and mcp.drive roles), which helps the agent decide when the tool is applicable. However, it does not explicitly mention when not to use it or point to alternatives like drive_search_items for OneDrive-only searches.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does mention the required delegated permission (Sites.Read.All) and the visibility constraint (only sites visible to the signed-in user). However, it does not describe return format, pagination, ordering, or error behavior, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The Chinese intent phrases add useful multilingual context without bloating the text, and every sentence contributes meaningful 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 simple two-parameter search tool with no output schema and no annotations, the description covers the essential aspects: purpose, auth requirement, and result scope. While it could mention return values or pagination, the description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because both parameters (query and top) have descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search'), the resource ('SharePoint sites'), and the scope ('visible to the signed-in user'). This distinguishes it from sibling tools like sharepoint_search_drive_items (searches drive items) and sharepoint_get_site (retrieves a specific site).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (searching SharePoint sites) and includes example Chinese intents for common use cases. However, it does not explicitly state alternatives or when-not-to-use scenarios, e.g., versus the broader search_sharepoint 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?
With no annotations, description provides key behavioral context: 'Unspecified fields remain unchanged' clarifies partial-update semantics, and 'Requires delegated Sites.ReadWrite.All' sets auth expectations. Lacks return-value and error behavior details, but the mutation behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise English sentences convey action, key nuance, and permission requirement. Chinese intent lines add multilingual coverage without redundancy. Front-loaded and 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?
Adequately complete for a simple update tool: says what it updates, how fields behave, and what permission is needed. Missing return-value description and failure modes, but these are not essential for invocation. No output schema increases responsibility, yet the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters (siteId/listId/itemId, fields as object keyed by internal column name). Description adds no parameter detail beyond echoing 'selected fields', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Verb 'Update' + resource 'SharePoint list item' clearly states the action. Distinguishes from sibling tools like sharepoint_update_list (updates a list definition) by targeting list items specifically, and 'selected fields' adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: update an existing list item. No explicit when-to-use vs alternatives, but verb+resource makes the use case self-evident. Permission requirement is a prerequisite rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the resulting messages are 'unread candidates' because Graph lacks a reliable cross-source unread flag. This is honest about the approximation. It does not mention side effects or read-only status, but the main limitation is clearly surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence is dense and informative; the second provides Chinese intents, which is useful for multilingual contexts but somewhat redundant for an English-only agent. Overall, it is efficient without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool aggregates heterogeneous messages (channels and chats) but has no output schema or annotations. The description does not explain the return format, how 'recent' is defined, or how 'unread candidates' are determined beyond the Graph limitation. This leaves gaps for an agent needing to parse the result or understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'limit', is already well-described in the schema ('Maximum number of message candidates') with 100% coverage. The description does not add any additional param-specific meaning, so it relies on the schema, which is sufficient. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Aggregate recent Teams channel and chat messages') and a clear purpose ('as unread candidates'). It distinguishes this from sibling tools like teams_list_channel_messages and teams_list_chat_messages by focusing on cross-source aggregation for unread detection, not just listing messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining why this tool exists ('Graph does not expose one reliable cross-source unread flag'), implying it is the choice for an aggregated unread view. However, it does not explicitly mention alternatives or exclusion criteria, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It adds the authenticated actor and permission requirement, which is useful. However, it does not disclose potential side effects beyond sending, such as whether the message is deliverable, failure modes, or behavior with HTML content. The description meets a baseline but does not add rich 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 a single concise sentence followed by useful multilingual intent list. It is front-loaded with the core action, and every word contributes—no fluff or redundant restatement. The structure is easy to scan and parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple send action with three well-documented parameters and no output schema, the description covers the essential context: purpose, actor, and permission. It lacks a hint about prerequisites, such as the chat needing to exist (teams_list_chats or teams_create_chat), but the sibling list and parameter name (chatId) imply this. Slight gap in not explaining that the chat must already be available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with descriptions: chatId ('Chat ID'), content ('Message content'), contentIsHtml ('Whether the content is HTML. Defaults to false.'). The tool description adds no additional parameter semantics beyond these, so the schema carries the load. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb-action pair: 'Send a message to a Teams chat as the signed-in user.' This specifies the resource (Teams chat) and distinguishes it from channel messaging (e.g., teams_send_channel_message). Including the Chinese intent translations reinforces the core purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the actor ('as the signed-in user') and the required permission ('Requires delegated ChatMessage.Send'). It does not explicitly mention when not to use this tool or point to alternatives like teams_send_channel_message, but the 'chat' vs 'channel' distinction in sibling names is implicit. Lacks an explicit exclusion or alternative recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses the permission requirement ('delegated User.Read.All'), which is a key constraint. However, it does not describe the return format, error behavior, or pagination details beyond what the schema's 'top' parameter implies. For a simple list operation, this is moderate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bilingual intent list. The core action is front-loaded, and the permission note and Chinese equivalents add value without unnecessary fluff. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters and no output schema. The description covers the operation and permission, and the schema fully documents the inputs. It does not explicitly describe the return value structure, but for a list operation the intent is clear from the name and description. This is sufficient for an agent to use the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'top' and 'userIdOrPrincipalName' having clear descriptions in the input schema. The description text adds no additional parameter semantics beyond what the schema already provides, so it relies on the schema to explain the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List direct reports for the signed-in user or another organization user.' It uses a specific verb ('List') and resource ('direct reports'), and it distinguishes itself from sibling tools like users_list, users_get_manager, and users_list_memberships by focusing specifically on direct reports. The inclusion of Chinese intents further clarifies the intended use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: whenever direct reports of a user are needed. It also mentions a prerequisite ('Requires delegated User.Read.All'). However, it does not explicitly contrast with alternative tools for related queries (e.g., users_list for all users, users_get_manager for a manager), so the guidance is clear but lacks explicit exclusions or 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?
No annotations are present, so the description carries the burden of revealing behavior. It adds meaningful context: 'directly belongs to' scopes the query to immediate memberships, and 'Omit the user to query the signed-in user' clarifies the optional parameter behavior. However, it lacks details on return format, pagination behavior beyond the schema's 'top' parameter, and any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a localized hint. It is front-loaded and every sentence contributes: first states the core action, second gives usage guidance. The Chinese intent section is an efficient localization addition without bloat.
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 list tool with optional parameters and no output schema, the description is reasonably complete. It explains the primary function and the key parameter behavior, and the sibling tool context makes the niche clear. However, it could describe the expected return values or clarify what 'directory objects' encompasses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions. The description adds no new information beyond the schema, as 'Omit the user to query the signed-in user' simply repeats the parameter description. It meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing groups and directory objects a user directly belongs to. It uses a specific verb ('List') and resource, and the qualifier 'directly' distinguishes it from transitive or broader membership queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use: to list memberships for a user, with the explicit note to omit the user for the signed-in user. It does not explicitly name alternative tools, but the context is clear enough to differentiate from sibling tools like users_get_profile or groups_check_my_memberships.
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?
With no annotations, the description carries the disclosure burden. It adds a permission requirement and indicates that only basic profile data is returned. However, it does not detail behavior like pagination, result ordering, or wildcard handling, leaving some ambiguity for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the core purpose. Including Chinese intent aliases adds practical value without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers essential aspects: purpose, query fields, permission, and return type. It lacks an output schema, but 'basic profile data' is adequate for an initial understanding. No significant gaps remain for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, the baseline is 3. The description reinforces the query semantics by restating the searchable fields, but adds no new information beyond the schema. The 'top' parameter is not elaborated beyond its schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search tenant users by name, email, or UPN' which clearly identifies the action (search), resource (tenant users), and search criteria. It also mentions returning basic profile data, distinguishing it from sibling tools like users_list and users_get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use: searching by name/email/UPN. It also notes the required permission (User.ReadBasic.All), which helps set expectations. However, it does not explicitly mention when not to use or name 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?
With no annotations, the description carries the transparency burden. It discloses key behaviors: polling, local caching, and that 'Token values are not returned.' It also notes 'Development only,' providing a usage constraint. However, it omits error/timeout 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 concise and front-loaded with the core action. The addition of Chinese intents is supplementary but still compact. Every sentence serves a purpose, though the localization list could be seen as extra.
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 one-parameter tool with no output schema, the description covers the essential flow (poll, cache, no token return) and the development-only caveat. It could be more complete by explicitly referencing the preceding auth_start_device_login step, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, timeoutSeconds, is fully described in the schema. The tool description does not add further parameter semantics, but with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Poll the token endpoint after the user enters the device code, then cache the token locally.' This distinguishes it from sibling auth tools like auth_start_device_login and auth_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 provides clear context for when to use: after the user enters the device code, and it restricts usage to 'Development only.' It does not explicitly name alternatives, but the sequencing with the device login flow is implied.
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?
With no annotations, the description carries the full burden. It does disclose the partial-update behavior and the required permission (delegated Calendars.ReadWrite), which are valuable. However, it omits potential side effects such as attendee notifications, and does not describe return values or error behavior, leaving gaps for a no-annotation, no-output-schema tool.
Agents need to know what a tool does to the world before 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 appropriately sized and front-loaded. The core action ('Update a calendar event') appears first, followed by the patch semantics, permission requirement, and compact Chinese intent list. Each element earns its place without verbosity or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, nested start/end objects, no annotations, and no output schema, the description covers the primary purpose, patch semantics, and permission but leaves out return value details, attendee notification behavior, and potential constraints (e.g., whether start/end must be updated together). The schema handles parameter documentation well, but the overall operational context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by stating 'Provide only the fields to change', which clarifies that unspecified fields remain untouched—a key intent for PATCH-style operations. This goes beyond the per-field 'New ...' descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Update a calendar event'. The phrase 'Provide only the fields to change' further distinguishes it from create/delete/cancel operations and clarifies the partial-update semantics. The listed Chinese intents (修改会议, 更新日程, etc.) reinforce the intended use case.
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?
'Provide only the fields to change' implies the tool is for modifying existing events rather than creating or deleting them, and the Chinese intent examples offer clear user-phrase triggers. The mention of 'Requires delegated Calendars.ReadWrite' gives a prerequisite, but it does not explicitly state when not to use this tool or compare it to siblings like calendar_update_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?
With no annotations provided, the description carries the full burden. It clearly indicates a read-only 'List' operation and discloses the specific auth requirement ('Requires delegated Files.Read'). It also specifies the user scope ('signed-in user'), which is valuable. It does not discuss pagination or output format, but these are less critical for a simple list operation.
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 core purpose, followed by a permission note and a list of Chinese intent examples. The intent list is useful for multilingual agent routing and not excessive. Each sentence serves a distinct purpose, and the overall length is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description adequately covers purpose, permission, and user-scope. It could mention that the result is limited to immediate children of the root or the optional top parameter, but those are already implied by the schema and the word 'root'. The Chinese intents enhance contextual completeness for language-driven invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the only parameter (top) with a clear description and bounds. The tool description adds no additional meaning to the parameter, so the baseline of 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List files and folders') and a specific resource ('the signed-in user OneDrive root'), clearly distinguishing it from sibling tools like drive_list_children or drive_search_items. The scope is explicit: root of OneDrive for the signed-in user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for root-level listing and includes Chinese intent phrases like '查看我的OneDrive' as examples of user queries that should route here. It also states the required permission (delegated Files.Read), providing a prerequisite. However, it does not explicitly contrast with alternatives such as drive_list_children or drive_list_recent.
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?
With no annotations, the description carries the full burden. It discloses a behavioral trait (requires delegated Mail.Read) and implies a read-only metadata operation, which is helpful. It could further clarify that it does not return file content, but 'metadata' sufficiently implies this.
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?
Two short sentences efficiently convey purpose and permission. The Chinese intent line adds practical multilingual usage hints without notable bloat, keeping the description appropriately sized.
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 single-parameter metadata listing, the description covers the operation, permission, and intent triggers. It omits specifics about returned fields, but this is acceptable given no output schema and the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter (messageId as 'Message ID'), providing 100% coverage. The description adds no additional parameter semantics beyond the context of 'for a message', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List attachment metadata for a message', using a specific verb and resource. It distinguishes from siblings like mail_get_attachment by specifying 'metadata' rather than content, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the permission requirement and including Chinese intent examples that map to typical user requests. However, it does not explicitly name alternatives or exclusions compared to sibling tools like mail_get_attachment.
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?
With no annotations provided, the description carries the burden. It clearly states 'Read' indicating read-only behavior, and discloses a required permission (delegated Sites.Read.All). This adds safety-relevant context beyond the schema. It does not cover error handling or response format, but the permission and read-only nature are key 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The Chinese intent translations add a bit of length but serve a functional purpose for multilingual support. Overall, it is appropriately sized with no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with 4 parameters and no output schema, the description covers the essential aspects: what it does, the permission requirement, and a hint at return fields. It does not detail optional parameter behavior (fieldNames), but the schema compensates. The sibling context and lack of output schema mean the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaningful parameter details beyond what the schema already provides; 'and its fields' loosely hints at fieldNames, but the schema already explains that parameter. The description adds minimal extra value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Read one SharePoint list item and its fields' with a specific verb ('Read') and resource ('SharePoint list item'). It clearly distinguishes this from sibling tools like sharepoint_list_list_items (listing multiple items) and sharepoint_update_list_item (updating). The Chinese intents reinforce the purpose for multilingual queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for retrieving a single list item by ID ('Read one'), which contrasts with listing tools. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select this over bulk or mutation 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?
With no annotations, the description carries the burden; it discloses the delegated permission requirement and the drive-return mapping. It does not detail pagination or error behavior, but for a simple list operation these gaps are minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with only two English sentences plus a Chinese intent hint. The Chinese phrase set adds minor redundancy but is compact and serves multilingual matching.
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 read/list tool, the description plus the full parameter schema covers the operation scope, auth requirement, and return model. The absence of an output schema is mitigated by the explicit 'returned as a drive' statement, though it doesn't describe response envelopes or failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the input schema already documents siteId and top. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action ('List'), the resource ('document libraries available in a SharePoint site'), and clarifies that each library is represented as a drive, which helps distinguish it from sibling SharePoint list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear operation context and a required permission ('Requires delegated Files.Read.All'), but it does not explicitly contrast with alternative tools such as sharepoint_list_lists or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool summarizes by multiple criteria, implying read-only aggregation, but does not explicitly state it does not modify messages or mention authentication requirements/rate limits. Adequate but not rich behavioral detail.
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?
Two sentences: first is the core definition, second provides useful multilingual intents for Chinese-language agents. No filler, appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 well-described params and no output schema, the description covers purpose and criteria sufficiently. It lacks explicit return format, but 'summarize' implies a text digest, which is reasonable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with clear descriptions (focus, hours). The description adds context about digest dimensions (urgency, sender domain, attachments) not captured in schema, enriching the agent's understanding of what the summary contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Summarize' with resource 'recent mail' and lists grouping dimensions (urgency, sender domain, read state, flags, attachments), clearly distinguishing it from low-level mail listing/searching siblings. Chinese intent examples reinforce the exact user-facing 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?
States what it does (summarize recent mail) and includes Chinese intents like '查看重要未读邮件' (view important unread mail), providing clear usage context. It does not explicitly name alternatives or exclusions, but the summarization function is distinct from search/list siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adds the key behavioral requirement that the signed-in user must be included in the members list. However, it does not disclose other behaviors such as permissions, side effects of creating a chat, or validation rules for one-on-one vs group chats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The inclusion of Chinese intents is slightly extraneous but not harmful. Overall, it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description provides adequate context: it explains the main function and a critical prerequisite. Some nuances about chat-type-specific constraints are not covered, but the schema fills most gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context for the 'members' parameter by instructing to include the signed-in user, which is not apparent from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('Teams chat'), specifying both one-on-one and group scope. This distinguishes it from sibling tools like teams_list_chats and teams_add_chat_member.
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 clearly implies when to use this tool (to create a new chat) and provides a critical guideline: include every participant, including the signed-in user. It does not explicitly mention alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral transparency. It states the destructive action (deleting cached tokens and pending login state) and adds a 'Development only' caveat, but it does not disclose potential side effects on the current session or clarify that this is local-only, which would be useful for a 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 extremely concise and front-loaded. The first sentence 'Development only.' immediately communicates the context, followed by a precise action statement. The Chinese intent examples add multilingual value without bloat. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is largely complete. It covers the purpose, the environment restriction, and the exact state cleared. However, it could go slightly further by stating whether this impacts server-side auth sessions or what the expected result is, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is trivially 100% covered. The baseline for no parameters is 4, and since there are no parameters to explain, the description does not need to add parameter semantics. It correctly avoids unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to delete locally cached tokens and pending device-code login state. It uses a specific verb ('Delete') with a clear resource and distinguishes itself from sibling auth tools like auth_start_device_login and auth_complete_device_login.
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 clear usage context: 'Development only.' This indicates when the tool should be used (development environments) but does not explicitly mention alternatives or exclusions beyond environment. The uniqueness of the action makes usage context reasonably 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?
With no annotations, the description carries the full burden of disclosing side effects. It explicitly states that attendees are notified and the required permission, which are critical. It doesn't mention irreversibility or the ultimate fate of the event, but the key behavioral aspects are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences covering the core behavior and permission, followed by Chinese intent examples. It is front-loaded and contains no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter cancellation tool with no output schema, the description covers essential context: the action, the actor constraint, required permission, and the notification side effect. It could benefit from explicit mention of when not to use it (e.g., when not the organizer), but it is adequately complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage, each with descriptions). The tool description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (cancel), the target resource (a meeting organized by the signed-in user), and the side effect (notify attendees). This distinguishes it from sibling tools like calendar_delete_event by emphasizing the notification behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: only meetings organized by the signed-in user can be cancelled, and it requires delegated Calendars.ReadWrite. However, it doesn't explicitly contrast with calendar_delete_event or calendar_respond_to_event, so it lacks explicit when-not 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?
With no annotations provided, the description carries the full burden. It usefully discloses the required delegated permission and the mutation implied by 'move.' However, it does not mention side effects like the item disappearing from the source folder or potential changes to sharing links, though these are somewhat inherent in the 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 two sentences long, front-loaded with the primary English purpose and permission requirement, followed by helpful multilingual intent aliases. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description covers the core operation and permission context. It lacks an explicit statement about return values, but for a move action, the outcome is generally clear. The multilingual aliases enhance completeness for Chinese-speaking intents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both itemId and newParentItemId have concise descriptions. The description adds no additional parameter detail beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a file or folder in the signed-in user's OneDrive to a new parent folder. It uses a specific verb and resource, and differentiates from siblings like drive_copy_item and drive_rename_item by explicitly indicating relocation.
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 by specifying the scope (signed-in user's OneDrive) and a prerequisite (requires delegated Files.ReadWrite). It does not explicitly mention alternatives or exclusions, but the action is unmistakable, and the Chinese intent aliases help recognize relevant user requests.
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?
With no annotations provided, the description carries the full burden. It discloses the required delegated Mail.ReadWrite permission, which is a critical behavioral trait. The verb 'copy' implies the original remains, but it does not explicitly mention side effects or reversibility. The auth disclosure is a valuable addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one main sentence, one permission note, and Chinese intents. It is front-loaded with the action and contains no fluff or redundant 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 simple two-parameter tool with no output schema, the description covers the core action, the permission requirement, and language variations. It does not explain return values or edge cases, but these are not essential given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both messageId and destinationFolderId. The tool description does not add further meaning beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action: 'Copy a message into another mailbox folder.' It uses a specific verb and resource, and the word 'copy' distinguishes it from sibling mail_move_message. The inclusion of Chinese intents also reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use (when a message needs to be copied to another folder), but it does not explicitly contrast with mail_move_message or state when not to use. The permission requirement adds context, but no alternative tools 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?
With no annotations provided, the description carries the full burden. It discloses the required delegated Mail.ReadWrite permission and explicitly states the draft is not sent. This is useful behavioral context, though it does not mention side effects like saving to the Drafts folder or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence followed by Chinese intent aliases. It front-loads the core purpose and permission requirement. No wasted words; the additional Chinese text is compact and serves multilingual support without bloating the definition.
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 6-parameter draft tool with no output schema and no annotations, the description provides the essential context: what it does, permission needed, and the non-sending guarantee. It lacks details on where the draft is stored or what the response contains, but these are not critical for tool selection. Overall, the description is largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 6 parameters, so per the rubric baseline is 3. The description does not add parameter-level info beyond what the schema already provides, but since the schema is complete, no deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the resource 'email draft', and the key distinction 'without sending it'. This distinguishes it from siblings like mail_send and mail_reply, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without sending it' provides clear context that this tool is for drafting emails when the user wants to prepare content but not transmit it yet. However, it does not explicitly name alternative tools (e.g., mail_send) or provide explicit exclusion scenarios, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It explicitly states the required permission (delegated Mail.Read) and the exact content read (body, sender, recipients, attachment flag). While it doesn't explicitly confirm non-mutating behavior, the verb 'Read' and the permission requirement imply a safe read 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 one clear sentence followed by a permission note and a compact list of Chinese intents. It front-loads the core function and avoids unnecessary words; the localized intent list enhances discoverability without bloating the description.
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 single-parameter read tool with no output schema, the description provides the essential context: action, content included, and permission required. It does not mention error behavior or response structure, but given the tool's simplicity, this is acceptable and nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, messageId, is fully described in the schema with 100% coverage, giving a baseline of 3. The description adds no additional parameter-level detail beyond the schema, though it mentions what content categories are returned, which is separate from parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and clearly identifies the resource as 'detailed content for a message' with enumerated elements (body, sender, recipients, attachment flag). This clearly distinguishes it from sibling tools like mail_list_messages (listing) and mail_get_attachment (getting attachments).
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 usage after obtaining a messageId, reinforced by the schema's parameter description 'Message ID from a mail list or search result.' It states the permission requirement ('Requires delegated Mail.Read') but does not explicitly mention alternatives or when not to use, missing the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is a write, may move the item to the recycle bin, and requires delegated Files.ReadWrite.All. This provides meaningful behavioral context beyond the schema, though it does not detail error outcomes or folder deletion semantics. Still, it is substantially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary action, and each sentence adds value. The Chinese intent list is a practical convenience without bloating the description. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter deletion tool with no output schema, the description covers purpose, behavior, auth, and localization. It omits potential error details or effects on folder contents, but these are not critical for basic usage. The information provided is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters (itemId, driveId) have descriptive explanations in the schema. The description itself adds no additional parameter guidance, so it relies on the schema. Baseline 3 is appropriate because the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a file or folder from a SharePoint document library, with a specific verb and resource. It distinguishes itself from sibling tools like sharepoint_delete_list_item and drive_delete_item by explicitly mentioning SharePoint library and file/folder scope. Chinese intent examples reinforce clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is a write operation for SharePoint library items and notes the required permission (Files.ReadWrite.All). It does not explicitly mention alternatives or exclusions, but the SharePoint library focus and permission requirement effectively guide usage. No explicit 'use this instead of' guidance, but the context is sufficiently 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?
With no annotations, the description carries the full burden. It clearly states the operation is read-only ('Read metadata'), covers both files and folders, and declares the required permission. It does not mention response format or potential errors, but for a simple read operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core purpose, the second provides the permission requirement and Chinese intents. Every part serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two fully described parameters and no output schema, the description is reasonably complete. It covers the purpose, permission, and scope (file or folder). It does not detail return fields, but the term 'metadata' is self-explanatory for a get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The tool description does not add additional meaning beyond the schema, such as how the parameters relate or example values. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads metadata for a SharePoint document-library file or folder, using the specific verb 'Read' and resource type. It distinguishes from siblings like sharepoint_download_file (which downloads content) and sharepoint_list_drive_items (which lists items).
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 that this tool is for reading metadata, and it also mentions the required permission (delegated Files.Read.All). However, it does not explicitly mention alternatives or when not to use it, such as for downloading content, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the delegated permission requirement (Channel.ReadBasic.All) and the dependency on a teamId obtained from another tool, which implies a read-only operation. It does not mention pagination or edge cases, but for a basic list tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences delivering purpose, prerequisite, and permission, followed by useful multilingual intent examples. There is no fluff or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description covers purpose, prerequisite, and auth. It lacks an explicit statement of return format or pagination, but the absence of an output schema and the straightforward nature of the operation make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage, describing teamId as 'usually from teams_list_joined_teams.' The tool description repeats this same guidance without adding new detail, so no significant value is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists channels in a Microsoft Teams team, using a specific verb and resource. It distinguishes itself from sibling tools like teams_get_team and teams_list_joined_teams by explicitly targeting the channels collection.
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 prerequisite guidance ('Use teams_list_joined_teams first to obtain a teamId') and a required permission, which helps the agent sequence calls correctly. It does not explicitly discuss alternatives, but the context is sufficient for a simple list operation.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds two valuable traits beyond the schema: it sends 'as the signed-in user' (identity context) and it requires delegated permission. It does not disclose error behaviors or rate limits, but for a simple send operation this is sufficient; it avoids hiding any destructive or surprising 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 extremely concise: two sentences plus localized intent aliases. The main action is front-loaded in the first sentence, the permission requirement is in the second, and the Chinese phrases are a compact list. There is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (4 parameters, no output schema, no nested objects). The description covers the essential context: what it does, who it acts as, and the required permission. It does not explain return values (not needed without output schema) and does not discuss failure conditions, but given the simplicity, the description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters (teamId, channelId, content, contentIsHtml) already having clear descriptions in the schema. The tool description does not add any extra meaning to the parameters, so it meets the baseline of 3 without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: 'Send a message to a Teams channel as the signed-in user.' The verb 'send' combined with the resource 'Teams channel' precisely matches the tool name and distinguishes it from sibling tools like teams_send_chat_message (for chats) and teams_reply_channel_message (for replies). The inclusion of Chinese intent aliases also reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by noting it acts as the signed-in user and requires delegated ChannelMessage.Send permission, which informs when it can be used. However, it does not explicitly mention alternatives or exclusions (e.g., 'use teams_send_chat_message for direct chats' or 'use teams_reply_channel_message for replies'), so it stops short of full alternatives 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?
No annotations are present, so the description carries the full burden. It adds a key privacy disclosure that token values are never returned, and the verb 'Inspect' implies read-only behavior. It does not mention network side effects or rate limits, but for a zero-parameter status tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with key information front-loaded in the first sentence. The Chinese intent mapping adds value without unnecessary bloat, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description conveys what information is exposed (auth state, token state, OAuth/OBO configuration, user details) and the critical privacy boundary. It is sufficient for a read-only diagnostic tool with no parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds meaningful context about what the status inspection covers, which is sufficient given no parameters 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 uses the specific verb 'Inspect' and enumerates the exact resources covered (MCP auth state, local token state, remote OAuth/OBO configuration, current request user details). It clearly distinguishes this tool from sibling auth tools that start, complete, or clear login flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it, including '诊断授权问题' (diagnose authorization issues) and checking login status. It does not explicitly name alternatives or exclusions, but the diagnostic intent and read-only scope differentiate it from mutation-focused auth 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?
With no annotations, the description carries the behavioral disclosure. It explains the permission requirement, the partial-update semantics, and that it applies to the signed-in user's mailbox. It does not detail return values or error behavior, but the essential mutation behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a compact Chinese intent line. It front-loads the purpose, adds a critical usage guideline, and includes the permission note 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, combined with the fully documented schema, gives enough context for correct invocation. It covers permission, scope, and partial-update semantics. It lacks output/error details but this is acceptable given no output schema and the tool's relative simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by stating that only the fields to change need to be provided, which clarifies the optionality and partial-update behavior beyond what the schema's individual field descriptions offer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a mailbox contact for the signed-in user, using a specific verb and resource. It distinguishes from sibling tools like contacts_create and contacts_delete, and explicitly notes partial updates with 'Provide only the fields to change.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly indicates this is for updating an existing contact and mentions the required delegate permission (Contacts.ReadWrite). It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select this tool over creation/deletion commands.
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?
Without annotations, the description effectively discloses key behavioral context: it requires delegated Files.ReadWrite permission and is intended for small files (implying size limitations). It does not mention overwrite/rename behavior or response format, but the schema covers conflictBehavior and the tool's purpose is not misrepresented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, size limitation/alternative, and permission requirement. The Chinese intent list is a useful add-on for multilingual agents and does not bloat the description. Front-loaded with the tool's primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, no output schema) and lack of annotations, the description covers the essential context: what it does, when to use it, and required permissions. It omits the return value and exact size limit, but the schema and the small/large distinction provide adequate guidance for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no extra parameter meaning beyond what the schema already provides (e.g., it doesn't explain the 'small' size threshold or clarify base64/text modes beyond schema definitions). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Upload a small file to the signed-in user OneDrive' with a specific verb (upload), resource (file to OneDrive), and scope (signed-in user). Contrasts with large-file upload sessions and identifies the target as OneDrive vs SharePoint, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides on when to use this tool ('small file') and when not ('Use upload sessions for large files'), providing an alternative. Also notes the required delegated permission (Files.ReadWrite), which is a prerequisite.
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?
With no annotations, the description must carry the burden for behavioral disclosure. It explicitly states 'Read', indicating a non-destructive, read-only operation. It also discloses the types of data returned (metadata, owner, type, quota). It does not mention potential edge cases like missing OneDrive or auth failures, but for a simple no-parameter read, the transparency is adequate and above average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the primary English description and a Chinese intent list. Every word contributes value, and the structure is front-loaded with the core purpose. It is concise without being under-specified.
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 is a simple, zero-parameter read operation with no output schema, the description is complete. It states the main purpose and the key data returned (metadata, owner, type, quota). There are no hidden parameters or side effects to describe, and the explanation is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. There are no parameter semantics to explain. The description does not need to add parameter details, and it appropriately focuses on the return values instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: 'Read signed-in user OneDrive metadata, owner, type, and quota.' It uses a specific verb ('Read') and identifies the resource (signed-in user's OneDrive). This distinguishes it from sibling tools like drive_list_root (lists files) or drive_get_item (gets a specific item), so purpose clarity is high.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: to retrieve the signed-in user's OneDrive metadata, including quota. The Chinese intents ('查看我的OneDrive信息, 查看网盘容量, 查看OneDrive配额') reinforce these use cases. However, it does not explicitly mention alternatives or exclusions (e.g., use drive_list_root for files). Thus it has clear context without explicit comparisons, aligning with a 4.
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?
With no annotations, the description carries the burden of disclosing behavior. It clearly labels the operation as 'Read', indicating a safe, non-destructive action, and lists the returned profile attributes. It does not mention auth prerequisites or error handling, but for a simple read-profile endpoint, the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the action and resource, the second gives usage context. The Chinese intent examples are a useful addition for multilingual support and do not bloat the description.
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?
This is a simple, zero-parameter tool with no output schema. The description fully covers its purpose, typical use cases, and return content. No additional context is necessary for an agent to select 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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details because there are none to document, and the schema coverage is effectively complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('signed-in user profile from Microsoft Graph /me'), clearly distinguishing it from sibling tools like users_get_profile by focusing on the current signed-in user. It also enumerates the exact data fields returned (email, display name, job title, department), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use for questions about account identity, email address, display name, job title, and department.' It does not explicitly exclude alternatives like users_get_profile, but the 'me' scope is clearly implied, providing sufficient guidance for most 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?
No annotations are provided, so the description must disclose behavior. It does so by stating the required permission (delegated Team.ReadBasic.All) and clarifying the 'directly joined' scope, which adds meaningful context. It does not mention response format or pagination, but that is not necessary for a zero-parameter list 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: two sentences, front-loaded with the purpose, and includes permission and multilingual intent hints without unnecessary padding.
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 zero-parameter list operation, this description covers the essential elements: what it does, under what conditions (permission), and scope. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema carries no burden. The baseline for 0 params is 4, and the description adds no parameter information, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 action (List), the resource (Microsoft Teams teams), and the scope (signed-in user has directly joined). It distinguishes from sibling tools like teams_get_team and teams_list_team_members by specifying the user's joined teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (when needing to list the signed-in user's joined teams) but does not explicitly mention alternatives or when not to use it, so it lacks full 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals crucial traits: the token is user-bound, one-time, and short-lived, and the tool never grants approval. However, it does not explicitly state potential side effects (e.g., whether the operation is destructive) or error behavior, which would add further 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 English text is concise, with two sentences that efficiently communicate purpose and usage. The addition of a Chinese translation line is redundant for an AI agent but does not harm clarity; it merely adds a bit of length. Overall, it is well-structured and free of 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?
For a tool with one parameter, no output schema, and no annotations, the description is fully contextual. It explains the exact flow (pending operation, web preview approval, token constraints), the precondition, and the tool's non-approval role. There are no significant gaps that would hinder correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes confirmToken as 'One-time token returned by the pending operation,' but the description adds meaningful semantics: the token is user-bound, short-lived, and must belong to the same signed-in user who approved the preview. This goes beyond the schema's basic type/role information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: 'Continue a pending sensitive operation after the same signed-in user approved its web preview.' This specifies the verb (continue), the object (pending sensitive operation), and the condition (after user approval), which distinguishes it from sibling tools like auth_complete_device_login that handle login flows, not operation execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call it only after the user says the confirmation page was approved' and 'This tool never grants approval itself.' This gives a clear when-to-use condition and a when-not-to-use (it does not approve), which is sufficient for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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