mcp-outlook-applescript

by hasan-imam

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation4/5
Most tools have distinct purposes, with clear separation between list/search/get, and each prepare/confirm pair is for a specific action. However, confirm_batch_operation overlaps with two prepare functions (delete and move), and set_email_flag vs clear_email_flag could confuse, though descriptions clarify.
Naming Consistency5/5
Tool names consistently follow a verb_noun snake_case pattern (e.g., list_emails, create_event, send_email). Minor deviations like confirm_batch_operation are still clear and readable, and the pattern is maintained across all 49 tools.
Tool Count2/5
With 49 tools, the server exceeds the recommended range for a coherent set. While the domain is broad (email, calendar, contacts, tasks, notes), the sheer number, especially the many prepare/confirm pairs, feels bloated and hard for agents to navigate efficiently.
Completeness3/5
Email and calendar have strong coverage (CRUD and management operations), but contacts, tasks, and notes are read-only with no create/update/delete tools. This leaves notable gaps for a comprehensive Outlook server, though agents can work around them for basic workflows.
Average 4.5/5 across 44 of 49 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 4 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 key behaviors: return fields (id, title, start/end dates, calendar_id, is_recurring flag), error conditions (start_date not before end_date, calendar unavailable), and optional parameters. This goes beyond the schema by explaining return structure and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with a clear lead sentence and logical flow: purpose, usage, return info, optional params, errors, and related tool. Each sentence contributes value, though it is slightly verbose in enumerating optional params.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 8-parameter tool with nested recurrence and no output schema, the description provides return fields and key error conditions, which helps the agent anticipate results. It does not fully elaborate on recurrence behavior or all-day event date conventions, but the schema covers parameter structure, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a baseline of 3 is appropriate. The description adds some cross-reference context (calendar_id from list_calendars) and lists optional parameters, but does not add constraints beyond the schema's detailed descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a calendar event in Outlook ('Create a new calendar event'), with a specific verb and resource. It distinguishes from siblings by mentioning the return of the created event and pointing to delete_event for removal, positioning it among related event tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context ('Use this to schedule meetings or reminders') and references list_calendars for calendar_id, as well as delete_event as an alternative for removal. It does not explicitly mention update_event for modification, but gives enough to differentiate from deletion and listing.
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 behavioral traits itself. It clearly states the side effect (setting the flag to 'not flagged'), the return type (success confirmation), and an error condition (non-existent email ID). For a simple mutation tool, this is sufficient, though it does not mention permissions or reversibility, which are less critical for a straightforward flag-clearing 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 three sentences, each adding necessary information: the core action, the equivalence to set_email_flag, and the return/error behavior. There is no redundant or filler content, making it appropriately concise 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?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description adequately covers the expected behavior, success output, and error case. It is complete enough for an agent to invoke the tool correctly, though it could potentially mention whether the operation is idempotent or what happens if the flag is already clear, but those are minor omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 single parameter email_id is already well-documented in the schema, including its type, bounds, and example source (list_emails or search_emails). The description does not add significant semantic value beyond restating the parameter's purpose, so a baseline score of 3 is appropriate given the 100% 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 (clear the follow-up flag), the resource (an email), and the resulting state (not flagged). It also distinguishes itself from the sibling set_email_flag by explicitly noting it is a convenience shortcut for flag_status 0, making its purpose unique 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 on when to use the tool (to clear a follow-up flag) and explicitly mentions it is a shortcut for set_email_flag, which helps the agent choose between the two. However, it does not explicitly state scenarios where one should prefer the generic set_email_flag over this shortcut, which is a minor gap.
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 that the tool moves the email, returns a success message, and errors on invalid, expired, already-used tokens, or when the email changed since prepare. This is helpful behavioral context, though it omits details such as permissions or reversibility.
Agents need to know what a tool does to the world before 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 short, focused sentences convey purpose, action, success output, and error conditions without redundancy. The description is front-loaded with the primary purpose and uses minimal 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 two-parameter tool with no output schema, the description adequately covers the workflow, success/failure behavior, and token validity constraints. It leaves some gaps (e.g., no explicit mention of idempotency or side effects beyond moving the email), but overall it is sufficient for an agent to select and 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 descriptions already explain both parameters (token_id as approval UUID, email_id must match prepare step), so the description adds little beyond reinforcing the token source. The 100% schema coverage means the description is not required to compensate, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool confirms and executes an email archive using a token from prepare_archive_email, naming the specific action (moves to Archive folder). It distinguishes itself from the prepare step and other confirm tools by referencing the Archive folder and the token workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs that the token comes from prepare_archive_email and describes error conditions, implying this is the follow-up step in a two-phase operation. It does not explicitly name alternatives, but the context of sibling confirm tools and the reference to the prepare step provides sufficient 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, the description discloses key behaviors: moving email to Deleted Items, returning success/error messages, and failure modes for token issues or email changes. This is substantial transparency, though it omits 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?
Three short sentences efficiently cover action, effect, and error conditions, with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 is sufficient for a 2-parameter tool with a prior prepare step, explaining workflow, outcomes, and errors. It lacks details on the success message format but that is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters well-described. The description adds minimal parameter-specific detail beyond what the schema provides, 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 tool confirms and executes email deletion using a token from prepare_delete_email, distinguishing it from sibling confirm_* tools by specifying the deletion action and the Deleted Items folder outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 identifies the prerequisite step (prepare_delete_email) and implies this tool should be used only after that, with explicit error conditions for invalid/expired tokens. However, it does not explicitly state when not to use it, so a score of 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 transparency burden. It discloses the return value ('Returns the created folder with id, name, messageCount, and unreadCount'), error condition ('Returns an error if the parent folder does not exist'), and the default vs. subfolder behavior. While it doesn't mention duplicate names or permissions, it provides substantive behavioral detail beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, all relevant and without redundancy. It front-loads the core purpose in the first sentence and then efficiently covers key usage details, return values, and error handling. Each 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 simple create tool with two well-documented parameters, the description is fairly complete. It covers the default behavior, subfolder option, how to obtain parent IDs, the return object, and the error case. It could mention duplicate folder name handling, but given the simplicity and lack of output schema, the description sufficiently prepares an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds marginal meaning beyond the schema: it clarifies that omitting parent_folder_id creates a top-level folder, which is already in the schema description for that parameter. No additional semantics are provided for the 'name' parameter beyond what 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?
The description clearly states the action: 'Create a new mail folder in Outlook.' and distinguishes from siblings like rename_folder, move_folder, and delete_folder. It adds specificity by explaining top-level vs. subfolder creation, 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 provides clear context on when to use this tool and key prerequisite guidance: 'Use list_folders to discover existing folder IDs for the parent.' It also clarifies the default behavior (top-level) vs. subfolder usage, which helps agents decide when to include parent_folder_id. However, it doesn't explicitly state alternatives or when not to use it, but the instruction to consult list_folders serves as a useful guideline.
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 the action is 'permanent and cannot be undone', returns a confirmation message, and returns an error for nonexistent IDs. It stops short of discussing permissions or cascading effects, but core destructive semantics are well 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 with four sentences, each adding useful information: the action, recurring-event nuance, permanence, and verification advice. It is front-loaded and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (delete with recurring-event nuance) and lack of output schema, the description covers the essential behavior, error cases, and prerequisite verification. It does not detail the exact confirmation message structure but mentions it clearly. Minor omissions like idempotency behavior prevent a perfect 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?
Schema description coverage is 100%, with both event_id and apply_to already having descriptive text in the schema. The description adds little beyond restating the apply_to choice; it does not provide examples or clarify nuances beyond what the schema states. Baseline 3 is appropriate given the 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 opens with 'Delete a calendar event from Outlook', specifying a clear verb, resource, and platform. This distinguishes it from sibling tools like get_event, create_event, and update_event, 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 usage context by explaining the apply_to parameter for recurring events and advising 'Use get_event to verify the event before deleting'. However, it does not explicitly state when not to use the tool or mention alternative deletion methods for other resources, which would deepen the 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 burden. It discloses return behavior (success confirmation, error if email ID does not exist) and mentions reversibility, but does not cover permissions, idempotency, or any side effects beyond the state change. The disclosure is adequate but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver purpose, usage, and behavioral outcomes without redundancy. The description is front-loaded with the main action and each subsequent sentence adds essential information (clear unread indicators, success/error behavior, reversal tool).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 mutation tool, the description covers purpose, usage, return behavior, and reversal. It lacks only minor details like permission requirements or idempotency, but these are not critical given the tool's simplicity and the schema's 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?
Schema coverage is 100%, and the parameter email_id is already described in the schema as 'The email ID to mark as read (e.g., from list_emails or search_emails)'. The description adds no parameter-specific semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Mark an email as read in Outlook') and clarifies the exact purpose ('clear unread indicators'). It distinguishes itself from siblings by explicitly naming mark_email_unread as the reverse action, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context ('Use this to clear unread indicators on a message') and explicitly names the alternative/reverse tool ('Use mark_email_unread to reverse this action'). This qualifies as explicit alternatives and when-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, the description carries the full burden and does well: it discloses that the tool returns a preview and an approval token, that the token expires after 5 minutes, and that an error is returned for non-existent email IDs. It implicitly conveys that no mutation occurs until confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions 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, front-loaded with the purpose. Each sentence delivers essential information: the action, the return value, the next step, and token expiry. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a preparation step in a two-phase operation, the description covers the essential context: what it returns, how to proceed, and error/expiry behavior. It does not detail the preview content or mention permissions, but these are not critical for correct invocation. With no output schema, 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?
The input schema already fully describes the single parameter email_id, including type, constraints, and source examples. The description adds no additional parameter semantics beyond restating the email ID, so with 100% 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 purpose: to prepare an email for marking as junk (move to Junk folder). It distinguishes from the actual execution step by explicitly naming confirm_junk_email as the follow-up, using a specific verb ('prepare') and resource ('email').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by describing the two-step workflow: call this tool to get a token, then call confirm_junk_email with that token. It does not explicitly list alternatives, but the naming and flow make the intended usage evident.
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 full burden. It discloses non-execution (requires confirm), return of preview and token, error on invalid IDs, and token expiry. Could explicitly state 'this does not move the email' but the flow implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four focused sentences, front-loaded with the main purpose. Every sentence adds essential operational detail 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?
Covers purpose, return value, next step, error conditions, and token expiration. With no output schema or annotations, this is sufficiently complete for a two-parameter prepare 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 baseline applies. The description adds existence-check context but no new parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action 'Prepare to move an email to another folder', clearly distinguishing it from confirm_move_email and batch variants. The verb+resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call confirm_move_email with the token, establishing a clear two-step flow. Does not explicitly mention the batch alternative, but sibling names and the description's focus on single-email move make the context 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 burden of behavioral disclosure. It states that the folder is not moved, describes the success confirmation output, and specifies the error condition for non-existent folder IDs. It does not cover permissions or reversibility, but for a rename operation 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 three sentences, each informative and directly relevant. It front-loads the main action, then provides scope, return behavior, and a usage tip. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema and no annotations, the description covers purpose, behavior, error handling, and a source for folder IDs. It lacks permission requirements or more detailed return structure, but the essentials are present 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 schema already provides 100% coverage of parameter descriptions, including meaning and examples. The description adds a helpful hint to use list_folders for finding folder IDs, but this is minor additional value beyond the schema, 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 identifies the action as renaming a mail folder in Outlook, with the specific scope of changing the display name only. It explicitly distinguishes itself from move_folder by stating 'without moving it', and the verb+resource combination is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by mentioning that list_folders should be used to find folder IDs, and implicitly indicates this tool is for renaming rather than moving. However, it does not explicitly state when not to use this tool or mention alternatives like create_folder or move_folder.
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 that sending is immediate and irreversible ('cannot be undone'), describes return values ('message_id and sent_at timestamp'), and specifies error conditions for missing required fields or invalid attachment paths. This covers the most critical behavioral aspects, though it omits potential details like authentication requirements or size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a distinct purpose: capabilities, immediacy/irreversibility, return value, and error handling. It is front-loaded with the primary purpose and contains no filler or redundant rephrasing of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 10 parameters, no annotations, and no output schema, the description provides essential context: purpose, side effects, return information, a cross-tool dependency, and error behavior. It does not exhaustively explain every parameter, but the schema compensates. The absence of details like rate limits or asynchronous behavior 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 schema already covers 100% of parameters with rich descriptions, examples, and defaults, so the description adds limited parameter-level value. It does provide a useful pointer for account_id ('Use list_accounts to find account_id') and summarizes optional capabilities, but these are contextual rather than essential. The baseline of 3 is appropriate 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 begins with a specific verb-object pair 'Send an email from Outlook' and clearly enumerates supported features (CC, BCC, attachments, inline images, HTML). This unambiguously distinguishes it from sibling tools, none of which send email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 action sends immediately and cannot be undone, providing a clear caution. It also gives a direct prerequisite cross-reference: 'Use list_accounts to find account_id if sending from a non-default account.' It does not explicitly name alternative sending tools, but none exist among siblings, so 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 fully discloses key behaviors: it replaces existing categories, supports clearing via empty array, returns a success confirmation, and errors on nonexistent email IDs. It also advises checking current categories first. This gives a solid understanding of the operation's effects and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core purpose. Each sentence adds value: purpose, use case, clearing behavior, return/error behavior, and a pre-check recommendation. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter tool with no output schema or annotations, the description is quite complete. It covers the action, the replacement behavior, clear option, success/error results, and a workflow suggestion. It could mention potential prerequisites or restrictions, but for this straightforward operation, 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 schema already provides 100% coverage, including descriptions for email_id and categories, with an example and empty array usage. The description adds some context by saying 'color-coded labels' and recommending get_email before modifying, but these are not significant parameter-level details 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's function: 'Set categories on an email, replacing any existing categories.' It uses a specific verb and resource, and mentions 'color-coded labels' and 'organize emails,' which distinguishes it from sibling tools like mark_email_read or set_email_flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use: 'Use this to organize emails with color-coded labels.' It also recommends using get_email to check current categories before modifying, and explains how to clear all categories (empty array). However, it does not explicitly mention when NOT to use this tool 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 full burden. It discloses the core mutation (moves email to Junk folder), the success return (a message), and specific failure modes (invalid, expired, already used token; email changed). This provides substantial behavioral transparency beyond the schema, even if it doesn't address reversibility or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences, front-loaded with the primary action, and every sentence adds value (action, result, error conditions). No redundancy or 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 two-parameter tool with no output schema, the description is complete: it explains the prerequisite flow, the action's effect, the success return, and error conditions. The agent has enough context to invoke and interpret results without missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 already have descriptions. The description adds minimal extra parameter meaning—it notes the token comes from prepare_junk_email and mentions 'email has changed' as an error, which indirectly clarifies email_id's role, but this mostly echoes existing schema text. 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+resource: 'Confirm and execute marking an email as junk' using a token from prepare_junk_email, and specifies the action 'Moves the email to the Junk folder.' This clearly differentiates it from sibling confirmation tools like confirm_delete_email or confirm_move_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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: after prepare_junk_email has been called to obtain a token. It also warns about token validity and email-changed errors, setting expectations for preconditions. However, it does not explicitly name alternatives or state 'when not to use' this tool, though the sibling context is similar.
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 that the tool returns an error for non-existent note IDs and specifies the fields returned (summary fields plus body, createdDate, categories). This gives a clear picture of the operation's outcome and failure mode for a read 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 long, front-loaded with the action, then usage, then return details. Each sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool without an output schema, the description adequately covers the return value ('all summary fields plus body, createdDate, and categories') and the error condition. It is complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 single parameter note_id is well-documented in the schema with a description and constraints. The description adds context about using IDs from list_notes or search_notes, but this is largely redundant with the schema's '(e.g., from list_notes or search_notes)', so it provides minimal 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 uses 'Get full details of a single note' which is a specific verb+resource. It also distinguishes from siblings by saying 'Use this after list_notes or search_notes to read the complete note content', clearly separating it from listing or searching 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 explicitly states when to use the tool ('after list_notes or search_notes') and also mentions that an error is returned if the note ID does not exist. It doesn't mention alternatives or when not to use it, 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.
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 disclosing behavior. It states that the operation relocates the folder and all its contents, returns a success confirmation, and returns an error if either ID does not exist. This covers the main behavioral aspects, though it does not mention reversibility or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each providing essential information: purpose, effect, return/error behavior, and a usage hint. It is front-loaded and contains no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description is complete for a simple move tool. It covers the action, the scope (all contents), the success/error responses, and how to obtain necessary IDs. Nothing critical is missing for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters, including the example 'from list_folders'. The description adds little beyond this, mainly reinforcing the hint to use list_folders. It does not clarify additional formatting or relationship details 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 states a specific action: 'Move a mail folder under a different parent folder in Outlook.' It clearly distinguishes this from sibling tools like rename_folder (which changes name) and delete_folder, and further elaborates 'Relocates the folder and all its contents to the new parent.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context: moving a folder to a different parent. It also provides a practical instruction: 'Use list_folders to find folder IDs.' However, it does not explicitly state when not to use this tool or compare it directly to alternatives like rename_folder.
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 exist, so the description carries the full burden. It discloses the preview, approval token, 5-minute expiration, and error on nonexistent email ID. It also implies the actual move does not happen until confirmation, though it doesn't state that explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions 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, front-loaded with the main purpose. Each sentence earns its place: purpose, workflow, and token expiration/error conditions.
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 single-parameter tool with no output schema, the description covers the core workflow, next steps, expiration, and error handling. It is sufficiently complete for an agent to invoke and proceed 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 the parameter description already explains the email_id and provides source examples (list_emails or search_emails). The description adds the error-on-nonexistent-ID behavior, but this relates to validation rather than new parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific verb and resource: 'Prepare to archive an email (move to Archive folder)'. It distinguishes itself from sibling confirm_archive_email and other prepare_* tools by detailing the two-step flow with a preview and approval token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Call confirm_archive_email with the token to execute', making the sequential workflow clear. It implies when to use this tool (as a prerequisite before confirmation) without explicitly naming alternatives, but the sibling context reinforces the purpose.
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 transparency burden. It discloses the return of a preview with message count, an approval token, token expiry after 5 minutes, and error behavior for non-existent folder IDs. It implicitly conveys that no deletion occurs until confirmation, but doesn't mention potential 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?
Three concise sentences: purpose, return/next step, and error/expiry. Front-loaded with the main purpose and zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the response (preview with message count, token), the necessary next action, error behavior, and token expiry. For a simple single-parameter tool, this is 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 a complete description for the single folder_id parameter (e.g., from list_folders). The tool description adds no additional parameter-level details, 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 tool prepares to delete a mail folder and all its messages, with a preview and approval token. It distinguishes itself from confirm_delete_folder and other folder operations like prepare_empty_folder by specifying it's a preparatory step for deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call confirm_delete_folder with the token to execute, making the usage flow clear. It doesn't explicitly mention alternatives or exclusions, but the context is well-defined for a two-step 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?
With no annotations provided, the description carries the transparency burden. It discloses that the tool does not delete yet (prepares), returns a preview and token, that the token expires after 5 minutes, and that invalid IDs return an error. This goes beyond basic descriptions of similar tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences, front-loaded with purpose, then return value and next step, then error/expiry. Every sentence earns its place with no redundancy or irrelevant detail.
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 prepare step with no output schema, the description covers the essential context: preview, approval token, next step (confirm tool), error handling, and token expiration. This is sufficient for an agent to invoke the tool and understand the expected flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 single parameter folder_id is fully documented in the schema (description: 'The folder ID to empty (e.g., from list_folders)'). The description adds only the error behavior for invalid IDs, which is not parameter semantics. With 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Prepare to empty a mail folder by deleting all its messages.' This clearly distinguishes it from sibling tools like confirm_empty_folder (which executes the deletion) and prepare_delete_folder (which deletes the folder 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?
It explicitly instructs when to use the tool and the sequential flow: 'Call confirm_empty_folder with the token to execute.' It also notes an error condition (invalid folder ID). It doesn't explicitly exclude alternatives, but the two-step pattern is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states the destructive nature (permanently deletes folder and all messages), the success response, and error conditions (invalid/expired/used token, folder changed). This is comprehensive disclosure 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?
Three sentences, front-loaded with the core action, followed by consequences and error conditions. Every sentence adds essential information with 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?
The description covers purpose, prerequisites (token from prepare step), behavioral guarantees, and failure modes. It could explicitly say 'call prepare_delete_folder first' but the token reference implies it. No output schema means return-format details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both token_id and folder_id already documented. The description adds minimal extra meaning beyond restating that the token comes from prepare_delete_folder and the folder must match the prepare step, which the schema already notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 confirm and execute deletion of a mail folder using a token from prepare_delete_folder. This specific verb+resource combination distinguishes it from sibling confirmation tools like confirm_delete_email and confirm_move_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 token comes from prepare_delete_folder, implying this is the second step in a two-phase deletion. It does not explicitly list when-not-to-use or alternatives, but the token requirement makes the usage context unmistakable.
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 explains ordering, body preview, return shape, pagination, date filtering, and the prerequisite that Outlook must be running. It does not mention all potential edge cases but covers key behaviors well.
Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose, then progresses to details like preview size, return structure, pagination, and alternatives. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6-parameter schema and no output schema or annotations, the description covers the essential aspects: purpose, ordering, preview, return shape, pagination, filtering, and environment requirement. It could elaborate on the structure of individual items but the provided information is sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions, so baseline is 3. The description adds usage semantics by explaining how to paginate with offset/limit and how to use after/before together, going beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists email summaries in a specific folder, ordered newest first. It distinguishes from siblings by specifying the summary format and pagination behavior, and also references get_email for full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (browsing summaries by folder) and explicitly names get_email as the alternative for full email content. It does not explicitly contrast with search_emails, but the folder-scoped use case is evident.
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 reveals the return structure ({items, count, hasMore}) and the pagination contract, which is valuable. It also implies that items contain contact IDs (by referencing "a matching ID") without exposing full details. While it doesn't mention rate limits or exceptions, the core behaviors are transparently disclosed 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 exceptionally concise: two sentences that cover functionality, return structure, pagination behavior, and an alternative. There is no redundancy or filler. Each sentence earns its place, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately explains the return format and pagination. It also provides a next-step action (call get_contact). It does not specify the exact structure of items beyond implying IDs, nor does it cover potential errors or edge cases, but given the tool's simplicity (three parameters, no nested objects), it is reasonably complete for an agent to invoke and interpret results.
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 schema already documents each parameter in detail. The description adds semantic value beyond the schema by explaining how limit and offset work together in a pagination loop ("increment offset by limit when hasMore is true"), which is not explicitly stated in the parameter descriptions. It also clarifies that query is matched against contact names, aligning with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "Search contacts by matching the query against contact names." This specifies the verb (search), resource (contacts), and matching mechanism (against names), distinguishing it from sibling tools like list_contacts (which likely lists all contacts without a query) and get_contact (which fetches full details). It also explicitly points to get_contact for full details, further clarifying its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides actionable usage guidance: it explains the pagination pattern with "increment offset by limit when hasMore is true" and directs users to get_contact for full details, serving as an alternative. It does not explicitly enumerate when not to use this tool versus listing contacts, but the contrast with get_contact is clear. The guidance is practical and context-specific.
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 and does well. It discloses metadata-only returns, the response shape {items, count, hasMore}, and pagination behavior (increment offset by limit). It omits potential rate limits or sorting behavior, but for a read-only search tool, the core behavioral traits 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 and well-structured. It opens with the core purpose, then provides operational details on return shape, pagination, and filters. Every sentence contributes useful information with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description effectively explains the return format and pagination pattern. It covers filtering, folder scoping, and points to get_email for content. It lacks sorting details or default folder behavior, but for a search tool with this complexity, it is sufficiently 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, but the description adds meaningful context: pagination semantics ('increment offset by limit when hasMore is true'), result size ('~400 bytes each') to justify high limits, and the intended use of after/before for received-date filtering. This goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Search emails by matching the query against subject line and sender address.' It also distinguishes the tool from get_email by explicitly noting that it returns metadata only and no body preview, clarifying its role among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use this tool and when to use an alternative: 'For email content, call get_email on a matching ID.' It also explains filtering with after/before and folder_id, and pagination with offset/hasMore. However, it doesn't explicitly contrast with list_emails, which is a related sibling.
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 reveals the return structure ({items, count, hasMore}), explains pagination semantics (increment offset by limit when hasMore is true), and clarifies the matching field (task names). This goes beyond a simple operation statement, though it omits details like error behavior or read-only status, which are not critical 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 sentences long, front-loads the core purpose, and packs in return structure, pagination guidance, and a cross-reference to a sibling tool—all without superfluous words. 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?
The tool is simple, but there is no output schema and no annotations, so the description must cover both return shape and safety. It does supply the return shape and pagination behavior, and the search intent inherently implies a read operation. Missing details like sorting or error cases are minor, and the reference to get_task helps round out the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all three parameters, so the baseline is 3. The description adds value by explaining how offset and limit work together for pagination ('increment offset by limit when hasMore is true'), which is not explicit in the schema. It also reinforces that query matches task names, complementing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search tasks by matching the query against task names.' This includes a specific verb (search), a resource (tasks), and a precise scope (task names), distinguishing it from sibling tools like search_emails or list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 pointer for when to use an alternative: 'For full task details, call get_task on a matching ID.' It also implies this is the tool for name-based search, but it does not explicitly state when to prefer this over list_tasks or other search tools, so a small gap remains.
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 the mutation (moving the email), the success response, and several error conditions: invalid, expired, or already-used token, and email changed since preparation. This is substantial transparency, though it doesn't detail reversibility or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences with no redundancy. It front-loads the core purpose, then briefly explains the action, return value, and failure modes. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-step confirmation tool with two parameters and no output schema, the description covers the necessary context: the precondition (token from prepare), the action (move to specified folder), the return (success message), and error cases. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters, giving 100% coverage. The description adds meaningful context by explaining the token originates from prepare_move_email and that the email_id must match the prepare step, clarifying the relationship between parameters and the workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: it confirms and executes moving an email using a token from prepare_move_email. It specifies the resource (email) and the action (move), and distinguishes it from sibling tools like confirm_delete_email and confirm_archive_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 this is a follow-up step to prepare_move_email, stating it uses a token from that step and moves to the folder specified there. It doesn't explicitly say when not to use it, but the token-based flow provides strong contextual guidance. No alternatives are mentioned, but sibling similarities are handled by the naming and token reference.
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 and does well: it discloses that it writes to a user-specified save_path, requires the parent directory to exist, returns the saved file path/name/size, and lists specific error conditions (missing email/attachment, invalid directory, size limit). It lacks detail on overwrite behavior or authentication, but the provided transparency is strong.
Agents need to know what a tool does to the world before calling it. Descriptions 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 three-sentence paragraph that front-loads the main purpose and then efficiently covers usage, return values, and error cases. Every sentence contributes necessary information, with no filler or repetition of schema basics.
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 file-download operation with no output schema, the description is highly complete: it covers prerequisites (list_attachments, existing directory), return values (path, name, size), and failure modes. The absence of detailed return formatting is acceptable because the return fields are explicitly listed. The description leaves little ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with descriptions, but the tool description adds meaningful context beyond the schema: it clarifies that attachment_index is 1-based and obtained from list_attachments, and that save_path's parent directory must pre-exist. This adds value without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Download and save an email attachment to a file on disk.' This clearly distinguishes the tool from siblings like list_attachments (which lists attachments) and other email tools. It also mentions the 1-based index, making its purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Use this after list_attachments to get the 1-based attachment index,' providing a clear workflow context. It does not explicitly name alternative tools to avoid, but there is no other download tool among siblings, and the guidance is adequate for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It details what fields are returned and warns about errors for nonexistent IDs. It does not explicitly state read-only behavior, but 'Get' implies it. For a simple read tool, this is solid coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear structure: purpose, usage context, and return content/error behavior. The field enumeration is a bit long but valuable given no output schema. Every sentence earns its place.
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 single-parameter get tool with no output schema, the description fully covers what it returns, when to use it, and error behavior. It also references summary fields from sibling tools, providing complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains the contact_id. The description adds no new semantic detail beyond the schema's own explanation, 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 states the tool gets full details of a single contact, using a specific verb and resource. It distinguishes from siblings like list_contacts and search_contacts by explicitly positioning this as the follow-up for complete information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use this after list_contacts or search_contacts to see complete information.' This names the alternatives and clarifies when this tool is appropriate. Also notes an error condition for invalid IDs, reinforcing proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the return format ('object with a single "count" field (number)'), the optional folder_id, and the prerequisite 'Requires Outlook to be running.' This adds meaningful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with the purpose, then usage, return format, parameter detail, and prerequisite. Every sentence is necessary, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple count tool with one optional parameter, the description is complete. It covers purpose, usage, return format, and a prerequisite. No output schema exists, but the return value is clearly explained. No significant 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?
The schema already describes folder_id at 100% coverage, so baseline is 3. The description adds value by explaining the optional nature and directing to list_folders for obtaining folder IDs, which is a helpful cross-reference 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?
Clearly states the tool's function: 'Get the count of unread emails' with scope across all folders or a specific folder. It differentiates from siblings like list_emails by explicitly noting it's a 'quick check without fetching full email lists'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'Use this for a quick check without fetching full email lists.' It also references list_folders for obtaining folder IDs, guiding the user to a related tool. It doesn't name alternative tools explicitly but implies 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.
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 return structure ('array of calendar objects with id, name, and accountId') and the runtime prerequisite (Outlook running) and error condition. This is solid behavioral disclosure, though it doesn't mention side effects (likely none) or additional details like sort order.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the core function, the second gives usage direction, and the third describes the return format and a prerequisite/error condition. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete: it explains what it returns, in what structure, and the one critical environmental requirement. There is no missing information for an agent to invoke and interpret results.
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 there is no parameter guidance needed. The schema is empty with 100% coverage. The description appropriately focuses on output rather than parameters, which is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 'List' and resource 'calendar folders configured in Outlook', and distinguishes it from sibling tools like list_folders by specifying 'calendar folders'. It also explains its purpose in the context of other calendar operations, removing ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: to 'discover calendar IDs for filtering in list_events or specifying a target calendar in create_event'. It also notes the prerequisite that Outlook must be running and the error behavior. It doesn't address alternatives or when not to use it, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return shape ({items, count, hasMore}) and pagination behavior ('increment offset by limit when hasMore is true'), which are key behavioral traits. It does not cover potential side effects, but as a read-only list operation, this is sufficient and valuable.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences, front-loaded with purpose, and every sentence earns its place: purpose, return shape/pagination, and filter guidance plus pointer to get_event. No fluff or repetition of schema details.
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 list tool with no output schema and five parameters, the description covers essential invocation details: pagination, filtering, and how to get full event details. It is complete enough for an agent to call the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining relationships: 'Filter by date range (start_date + end_date in ISO 8601) and/or calendar_id (from list_calendars).' This clarifies how parameters combine and where calendar_id comes from, going beyond individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('calendar events') and scope ('optional date range or calendar filtering'). It distinguishes from siblings by noting it returns a paginated list and explicitly points to get_event for full details, making its role unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 this tool (listing with filters and pagination) and provides an explicit alternative: 'Use get_event for full details including attendees and description.' However, it does not explicitly address when not to use it versus search_events, a closely related sibling, so it misses full 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 burden of behavioral disclosure. It discloses both the success return ('Returns a success confirmation') and the error condition ('Returns an error if the email ID does not exist'), and implies reversibility by naming the reverse tool. It does not cover idempotency or permissions, but for a simple mutation this is a solid level of 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 three sentences, each earning its place: purpose, use case, return/error behavior, and reversal instruction. It is front-loaded with the primary purpose and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter mutation with no output schema, the description covers the essential context: what it does, when to use it, the success/error behavior, and how to reverse it. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 schema already fully describes the parameter (type, range, description, and example source). The tool description adds no additional parameter-specific meaning, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark an email as unread') on the resource ('in Outlook') with a specific verb and resource. It also distinguishes itself from siblings by mentioning 'restore the unread indicator' and explicitly naming the reverse tool, mark_email_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case ('Use this to restore the unread indicator on a message') and explicitly names the alternative/reverse action ('Use mark_email_read to reverse this action'). This gives the agent actionable guidance on when to choose this tool over its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: returns per-email tokens, supports selective confirmation, errors on non-existent IDs, and tokens expire after 5 minutes. It also makes clear the prepare step doesn't execute deletion, which is crucial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each with essential info: purpose, output, follow-up, error handling, and expiry. No wasted words, and the most important detail (prepare to delete) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the two-phase workflow, constraints, error conditions, and token lifecycle, making the tool self-contained even without an output schema. It tells the agent exactly what to expect and how to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 email_ids, including range, item type, and source examples. The description adds context about per-email tokens but no additional syntax or format details, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it prepares deletion of multiple emails (up to 50), distinguishing it from single-email prepare_delete_email and batch-move alternatives. The verb 'prepare' + resource 'multiple emails' gives specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: use when you want to delete multiple emails and selectively confirm via tokens. It explicitly directs to confirm_batch_operation for execution, but doesn't contrast with single-delete or batch-move tools. The 50-email limit and error behavior imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: it returns per-email tokens, defers execution to a later confirmation step, errors if any email or folder doesn't exist, and tokens expire after 5 minutes. This gives the agent a solid understanding of the tool's side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each adding a distinct piece of information: the operation, the workflow, and the error/expiry behavior. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description is complete for a two-phase operation. It covers the workflow, return tokens, validation errors, and token expiration, enabling the agent to sequence the operation 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 provides detailed descriptions for both parameters, referencing source tools like list_emails and list_folders, so baseline 3 applies. The description adds the 50-email limit and error condition but doesn't alter the parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 prepares a batch move of multiple emails (up to 50) to a destination folder, using a specific verb and resource. It distinguishes itself from single-email move tools and the confirm step by describing the two-phase approval token workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the workflow by instructing to call confirm_batch_operation with the returned tokens, providing clear context on when this tool is used. It doesn't explicitly name alternatives like prepare_move_email, but the batch focus (up to 50) makes the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does exceptionally well. It discloses that the tool returns a preview and an approval token, specifies expiration behavior (5 minutes), clarifies that deletion is deferred to a follow-up call, and describes the error condition for invalid IDs. This gives the agent a clear picture of the tool's behavior and 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 three sentences, front-loaded with the main purpose, and each sentence provides distinct value: purpose, workflow, and error/expiration details. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains what the tool returns (preview and token), the token's expiration, the required follow-up action, and an error condition. For a simple preparation tool, this is complete and covers all essential contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 email_id (type, format, example source), and schema coverage is 100%. The description adds context about error on non-existent ID but does not introduce new parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Prepare to delete an email (move to trash).' It distinguishes itself from the sibling tool confirm_delete_email by explaining this is the preparation step, and from prepare_batch_delete_emails by context (single email).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Call confirm_delete_email with the token to execute the deletion,' providing a clear sequential usage. It also notes an error condition for non-existent IDs. However, it does not explicitly mention alternatives like prepare_batch_delete_emails for batch deletion, though the sibling name makes this implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the mutation (updates RSVP status), the default side-effect (sends a notification to the organizer), how to suppress it (send_response=false), the return behavior (confirmation message), and error conditions (event ID not found or response unavailable). This is thorough and goes beyond what a tool name alone would imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, notification behavior, return message, and prerequisite/error handling. It's front-loaded with the main action and stays tightly focused without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with four parameters and no output schema, the description covers the key contextual needs: what the tool does, what side effects occur, what success returns, and what failure looks like. The 'use get_event first' guidance situates it within the event workflow relative to siblings. No further detail is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reiterates the send_response default and event_id source, but these are already in the schema. It adds the error scenario tied to event_id, but that's more about behavior than parameter meaning. No significant extra parameter insight 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 opens with a specific verb and resource: 'Respond to a meeting invitation with accept, decline, or tentative.' It clearly differentiates from sibling tools like create_event or update_event by focusing on the RSVP action. The mention of updating the RSVP status in Outlook reinforces the tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use get_event first to review the event details before responding,' providing a clear prerequisite. It doesn't name alternatives or conditions when not to use, but the instruction to review first is a solid guideline. An explicit alternative (e.g., 'For modifying event details, use update_event instead') would elevate to 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 discloses key behaviors: returns {items, count, hasMore}, pagination semantics (increment offset by limit when hasMore), and that results only match titles (not full event details). It doesn't mention ordering or error cases, but it reveals the most important aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, densely packed with purpose, return shape, filtering, pagination, and a pointer to get_event. No fluff or redundant repetition.
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 there's no output schema, the description explains the return structure and pagination clearly. It also gives the next step for full event details. It's complete enough to use the tool correctly without additional context.
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 practical semantics by explaining that after/before filter by event start date and that offset should be incremented by limit for pagination when hasMore is true, enhancing beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states "Search calendar events by matching the query against event titles," using a specific verb (search), resource (calendar events), and syntax (query against titles). This distinguishes it from sibling tools like list_events and get_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: after/before for date filtering, pagination with offset/limit, and points to get_event for full details. It doesn't explicitly mention when not to use it compared to list_events, but the title-matching scope implies that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns a success confirmation, returns an error if the email ID does not exist, and defines the meaning of the flag_status values. This is strong transparency for a simple mutation tool, though it does not mention permissions or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences containing purpose, usage values, an alternative, and error behavior. Every sentence adds value, with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers purpose, usage, error handling, and the alternative tool. It is sufficiently 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 coverage is 100%, so the schema already documents both parameters thoroughly. The description re-states the flag_status codes but adds little beyond what the schema provides, so it neither compensates nor harms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 sets the follow-up flag status on an email, specifying the exact resource and action. It also differentiates from the sibling clear_email_flag by offering it as a simpler clear-only alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use clear_email_flag for clear-only operations, providing a clear alternative. It also specifies the numeric flag_status values (1, 2, 0), telling the agent exactly how to achieve each state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the destructive outcome ('Deletes all messages') and enumerates specific error conditions (invalid, expired, already used token, or folder change). This is transparent about behavior and consequences.
Agents need to know what a tool does to the world before calling it. Descriptions 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, front-loaded with the main action, and every sentence serves a purpose: action, effect, and error conditions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow, success/error returns, and prerequisites. It doesn't mention permission requirements or what happens to the folder metadata, but for a confirmation tool, the essential context is present. Slight gap is acceptable given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds valuable meaning: token_id comes from prepare_empty_folder and folder_id must match the prepare step, which goes beyond property 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 ('Confirm and execute emptying a mail folder') and the specific resource (folder) plus the required token from prepare_empty_folder. It distinguishes itself from sibling confirmation tools like confirm_delete_folder by explicitly tying to the prepare step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 implies the tool should be used after prepare_empty_folder by mentioning the token requirement. It does not explicitly list when not to use it, but the context is strong enough to guide selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return shape ({items, count, hasMore}) and the pagination pattern (increment offset by limit when hasMore is true), which is useful behavioral context beyond the schema. It doesn't explicitly state it's read-only, but 'List' implies no 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?
Two sentences, no fluff. The first sentence states the action and return contract; the second gives pagination instruction and alternatives. 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 list tool with a simple schema, the description is quite complete: it covers purpose, return format, pagination behavior, and alternatives. It lacks details like sorting order or whether notes are from all folders, but these are minor for the tool's core use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers parameter meanings with 100% coverage, including defaults and ranges. The description adds the relationship between limit/offset and the hasMore flag, explaining how to use the parameters together for pagination, which goes beyond individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'note summaries from Outlook with pagination', which is a specific verb+resource combination. It also distinguishes itself from sibling tools by pointing to get_note for full details and search_notes for title-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use alternatives: use get_note for full body content, use search_notes for finding by title. This gives clear when-not guidance for list_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses partial update behavior ('Only the fields you specify will be changed'), recurrence handling via apply_to, the confirmation response with event ID and updated field names, and specific error conditions (event ID not found, start_date not before end_date). This is rich, non-obvious behavioral context beyond a simple update statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and each subsequent sentence delivers distinct value: partial update behavior, recurrence, return format, error conditions, and a pointer to get_event. There is no redundancy or filler; 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 8 parameters, no output schema, and no annotations, the description covers the essential operational context: what updates, how partial updates work, recurrence handling, return value, and error cases. It stops short of a 5 because it does not clarify how to clear a field (omission leaves unchanged, so no obvious mechanism) or discuss calendar scope/permissions, but these are minor gaps given the schema already covers parameter definitions.
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 important semantic context about parameter usage: omitted fields remain unchanged, apply_to distinguishes instance vs series updates, and start_date must precede end_date. These enrich understanding beyond the individual property descriptions, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Update a calendar event in Outlook', using a specific verb and resource. It clearly distinguishes update semantics from sibling create/delete/get tools by highlighting partial updates, and the context of recurring events with apply_to. This makes the tool's 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 useful guidance: it explains when to use apply_to for recurring events, warns that event_id must exist, and explicitly suggests 'Use get_event to review current values before updating.' However, it does not explicitly contrast with create_event or offer when-not-to-use exclusions, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure. It details return format (per-email results, summary with counts) and partial failure behavior (invalid, expired, or used tokens fail without blocking others). This goes beyond typical descriptions and is highly informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, each with a clear purpose: purpose, selective usage, return value, and partial failure behavior. It is front-loaded with the main action and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides sufficient detail on execution, return values, and error handling. It references the specific prepare tools and allows an agent to invoke the tool correctly without additional information.
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 schema already documents the tokens array. The description adds meaning by explaining the tokens come from prepare_batch* steps and that selective confirmation is possible by including only desired token/email pairs. This adds context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool confirms and executes a batch operation, specifically using tokens from prepare_batch_delete_emails or prepare_batch_move_emails. This distinguishes it from single-email confirm tools and clearly specifies the resource and verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when to use the tool (after prepare_batch* tools) and introduces selective confirmation, but does not explicitly mention alternatives (e.g., single confirm tools) or state when not to use it. This is still clear, but lacks a direct exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output contents ('Returns all summary fields plus location, description, organizer, attendees (with name and status), and recurrence IDs') and error behavior ('Returns an error if the event ID does not exist'), which adds meaningful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the main purpose front-loaded in the first sentence. It packs essential information—when to use, return payload, and error condition—without unnecessary detail.
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 single-parameter read operation, the description fully covers the tool's behavior: what it returns, when to use it, and when it fails. It is complete despite the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, including a description for event_id that mentions 'e.g., from list_events or search_events'. The description reinforces this usage context but does not add additional parameter semantics, 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 'Get full details of a single calendar event,' using a specific verb and resource. It distinguishes from siblings by referencing list_events and search_events as prior steps, and by focusing on full details for one event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Use this after list_events or search_events,' providing clear contextual guidance and naming alternative tools. It also implies the alternative is to use those tools for listing/searching rather than getting full details, covering the when and 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 full burden. It discloses the exact return fields (startDate, completedDate, body, hasReminder, reminderDate, categories) and error behavior. While it doesn't mention permissions or side effects, the absence of side effects for a get operation makes this sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, followed by usage context and return details. No fluff; every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the description thoroughly explains the return value with specific fields. For a simple read tool with one parameter, it covers purpose, usage, behavior, and error handling, which is 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?
The schema covers the parameter with 100% description, but the tool description adds context by indicating the ID comes from list_tasks/search_tasks and binding it to the error condition. This enriches the parameter's 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 'Get full details of a single task' with a specific verb and resource. It distinguishes from siblings by detailing that it returns complete fields (including ones not in list/summary) and by referencing list_tasks/search_tasks as prior steps.
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 says 'Use this after list_tasks or search_tasks to see the complete task,' providing clear when-to-use context and direct alternatives. It also notes the error condition for nonexistent IDs, adding practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns an array of attachment objects with specific fields, returns an error for nonexistent email IDs, and returns an empty array for emails without attachments. This covers success, error, and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences with no fluff. It fronts the purpose, then gives usage guidance, then describes the return format and edge cases, all in an efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully compensates by outlining the return array structure, error behavior, and empty case. It is complete for a one-parameter listing tool, covering all essential aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage for the single parameter email_id, including its type and description. The tool description adds context about using it to discover indices, but does not add significant parameter semantics beyond what the schema provides, 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 tool's function: 'List attachment metadata for a specific email.' It specifies the resource (attachments), the action (listing metadata), and distinguishes it from the sibling download_attachment by focusing on metadata rather than content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this before download_attachment to discover attachment indices and sizes,' providing a direct use case and naming an alternative. This gives clear guidance on when to use this tool versus the download 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 provided, the description carries the behavioral disclosure burden. It goes beyond a simple 'list' by revealing the return structure ({items, count, hasMore}) and pagination semantics. It doesn't mention auth or rate limits, but for a read-only list tool, the information given is sufficient and adds meaningful value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, pagination behavior, and alternatives. Front-loaded with the main action, no redundancy or filler. The structure is compact yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated list tool with no output schema, the description covers the essential aspects: what is returned, how pagination works, and how it relates to sibling tools. It is complete enough for an agent to invoke and interpret results without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with descriptions and defaults (100% coverage), so the baseline is 3. The description adds extra value by explaining the pagination relationship between offset and limit in the context of hasMore, which is not in the schema. This elevates the parameter understanding beyond raw field 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 begins with a specific verb and resource ('List contact summaries from Outlook') and clearly distinguishes from siblings by pointing to get_contact for full details and search_contacts for name-based search. This makes the tool's unique role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use alternatives: 'For full details... use get_contact' and 'Use search_contacts to find contacts by name.' It also gives pagination usage guidance, telling how to increment offset when hasMore is true, providing clear 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden and does so admirably. It discloses the exact search scope (titles only), the return structure {items, count, hasMore}, and the pagination behavior (increment offset by limit when hasMore is true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each essential: purpose/scope, return structure/pagination, and pointer to get_note. No fluff or redundant details.
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 3-param search tool with no output schema and no annotations, this description is completely adequate. It covers scope, output shape, pagination, and the next step for full content, leaving no significant 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 coverage is 100% with detailed parameter descriptions, so baseline is 3. The description adds value by explaining how to combine offset and limit for pagination, which goes beyond the individual schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches notes by matching against titles/names only, with an explicit exclusion of body content. This specific verb+resource+scope distinguishes it from search_emails and list_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for using the tool (search by title/name) and explicitly directs users to get_note for full content. Does not explicitly contrast with list_notes for listing all notes, but the pagination guidance and get_note pointer give useful usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses return fields (summary fields plus recipients, body, attachments, messageId, conversationId), the effect of strip_html on output format, and the error condition for a non-existent email ID. This goes beyond the schema by explaining response 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 four sentences that all convey essential information, front-loaded with the core purpose. No redundant or filler content exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the tool's purpose, usage context, parameter behaviors, and error handling sufficiently. It is 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning for strip_html by specifying the htmlBody field and for include_body by clarifying metadata-only behavior, improving upon the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get full details of a single email including its body content,' using a specific verb and resource. It differentiates from sibling tools like list_emails and search_emails by stating it is the follow-up to read the complete message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool after list_emails or search_emails for complete message details. Also provides guidance on when to set strip_html=false and include_body=false, giving clear context for parameter selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden and does so well. It discloses the return format ('Returns an array of accounts, each with id, name, email, and type fields'), a limitation ('only Exchange, IMAP, and POP account types are returned; newer Microsoft 365 account types may not appear'), and a prerequisite ('Requires Outlook to be running or returns an error').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then usage context, then return format and caveats. No redundant words; all three sentences carry meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return fields, includes an error condition, and notes a functional limitation. It fully covers what an agent needs to know to use the tool correctly, especially given its simple nature and lack of 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, so the schema already covers everything (100% coverage). The description adds useful context about how the output is used (e.g., discovering account IDs), but this is beyond parameter semantics. Given the baseline of 4 for zero parameters, this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all mail accounts configured in Microsoft Outlook for Mac.' It uses a specific verb and resource, and distinguishes itself from siblings by noting it discovers account IDs needed by other tools like list_folders.
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?
Explicit guidance is provided: 'Use this to discover account IDs needed by other tools (e.g., list_folders with account_id filter).' This tells the agent when to select this tool versus alternatives, and the mention of mail accounts differentiates it from other list tools like list_calendars.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses return format ('array of folders, each with id, name, messageCount, and unreadCount'), parameter effect ('grouped by account'), and error condition ('Returns an error if Outlook is not running'). These are all meaningful behavioral traits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, use case, return format, and error handling. It is front-loaded with the core action and is efficiently structured without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description covers all necessary context: behavior, return fields, parameter effect, and failure mode. It fully equips the agent to invoke the tool correctly and interpret results.
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% and includes a detailed description of account_id. The description adds the behavioral effect that providing account_id returns folders grouped by account, which is not in the schema and clarifies the output. This goes beyond 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 clearly states the tool lists all mail folders in Outlook with counts, and explicitly connects it to other tools needing folder IDs, distinguishing it from sibling list tools. The verb 'list' plus resource 'mail folders' is specific, and the usage context differentiates it from list_accounts, list_calendars, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to use the tool: 'Use this to discover folder IDs needed by list_emails, search_emails, prepare_move_email, and other folder-based tools.' This provides clear alternatives and purpose, fulfilling the when-to-use and implied when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It discloses the exact return shape ({items, count, hasMore}), pagination contract, and the summary-only nature, making behavior transparent for a read-only 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?
Two concise sentences: purpose first, then key behavioral details. Every sentence earns its place; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description provides return format, pagination, filtering, and an alternative for full details, covering all necessary context for an agent to use 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?
Schema covers all parameters (100% coverage), so baseline is 3. The description adds value by linking include_completed behavior and pagination offset/limit relationship, which enriches understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List task summaries from Outlook with pagination and optional completion filtering' using a specific verb and resource, and distinguishes from get_task by noting it returns summaries, not 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to get_task for full details including body and reminder, and provides clear usage guidance for pagination (increment offset by limit when hasMore is true) and filtering (set include_completed to false for incomplete tasks).
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:

[![mcp-outlook-applescript MCP server](https://glama.ai/mcp/servers/hasan-imam/mcp-outlook-applescript/badges/card.svg)](https://glama.ai/mcp/servers/hasan-imam/mcp-outlook-applescript)

Score Badge

Copy to your README.md:

[![mcp-outlook-applescript MCP server](https://glama.ai/mcp/servers/hasan-imam/mcp-outlook-applescript/badges/score.svg)](https://glama.ai/mcp/servers/hasan-imam/mcp-outlook-applescript)

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/hasan-imam/mcp-outlook-applescript'

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