The outlook-mcp server enables AI assistants to manage Microsoft Outlook email, calendar, attachments, SharePoint, and receipts/invoices via the Microsoft Graph API.
Email Management
List, search, retrieve, send, reply, forward, and create draft emails
Delete, move, archive, mark as read/unread, flag, categorize, and batch process emails
Calendar Management
List, create, update, and delete events (including recurring events)
Respond to invitations, find meeting times, check availability, and schedule online meetings (Teams/Skype)
List calendars, get calendar views, and check permissions
Attachment Handling
List, download, and add attachments to drafts
Scan for large or suspicious attachments; save with SHA-256 validation
Folder Management
List, create, rename folders; get folder statistics
SharePoint & OneDrive
Fetch files via sharing links or IDs, list files in SharePoint/OneDrive, resolve sharing links for metadata
Office Document Processing
Parse and extract content from PDF, Word (.docx), PowerPoint (.pptx), and Excel (.xlsx) files
Receipt & Invoice Collection
Extract structured receipt data (vendor, amount, currency), save attachment PDFs, fetch billing PDFs from email links, render emails to PDF, and collect all receipts for a period with idempotent re-run support
Authentication & Security
OAuth 2.0 with PKCE, encrypted local token storage, automatic token refresh, and headless/scheduled run support
Large File Support
Automatically saves files locally when they exceed MCP response size limits
Allows fetching billing PDFs from Stripe invoices via links in email bodies, with domain allowlisting and content validation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@outlook-mcp show my unread emails from today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants to interact with Microsoft Outlook email and calendar through the Microsoft Graph API.
Email Operations: Read, search, send, reply to emails and download attachments
SharePoint Integration: Access SharePoint files via sharing links or direct file IDs. Download files shared to you via emails.
Calendar Management: View and manage calendar events and appointments
Office Document Processing: Parse PDF, Word, PowerPoint, and Excel files with extracted text content
Receipt & Invoice Collection: Discover emailed receipts by sender/subject/date, save them as verified and consistently named PDFs (attachment, billing link, or rendered fallback), and stage a review draft — built for scheduled, non-interactive runs
Large File Support: Automatic handling of files that exceed MCP response size limits
Related MCP server: MCP Outlook Server
Choose your installation method:
Method | Best For |
Claude Desktop users | |
Claude Code, mcp CLI, other MCP clients |
Prerequisites: Before installing, you'll need to set up an Azure application to get your Client ID and Tenant ID.
For Claude Desktop users, DXT extensions provide the simplest installation experience.
Option 1: Download Pre-built Extension
Download outlook-mcp.dxt from the Releases page
In Claude Desktop, go to Settings → Extensions
Click Install from file and select the .dxt file
Enter your Azure Client ID, Tenant ID, and optional download directory when prompted
Option 2: Build from Source
Clone and install dependencies:
git clone https://github.com/XenoXilus/outlook-mcp.git
cd outlook-mcp
npm installInstall the DXT CLI: npm install -g @anthropic-ai/dxt
Pack the extension:
dxt pack . outlook-mcp.dxtInstall the generated .dxt file in Claude Desktop as above
For CLI-based MCP clients (Claude Code, mcp CLI, etc.), configure the server directly.
1. Clone and Install:
git clone https://github.com/XenoXilus/outlook-mcp.git
cd outlook-mcp
npm install2. Configure your MCP client:
Add the following to your MCP servers configuration (location varies by client):
{
"outlook-mcp": {
"command": "node",
"args": ["/absolute/path/to/outlook-mcp/server/index.js"],
"env": {
"AZURE_CLIENT_ID": "your-azure-client-id",
"AZURE_TENANT_ID": "your-azure-tenant-id",
"MCP_OUTLOOK_WORK_DIR": "/optional/download/directory"
}
}
}Common config file locations:
Claude Code: ~/.claude.json or project-level .mcp.json
mcp CLI: ~/.config/mcp/servers.json
3. Alternative: Use environment variables
Instead of specifying env in the config, you can export the variables in your shell:
export AZURE_CLIENT_ID="your-azure-client-id"
export AZURE_TENANT_ID="your-azure-tenant-id"
export MCP_OUTLOOK_WORK_DIR="/optional/download/directory"To use this MCP server, you need to register an application in Microsoft Azure.
Go to the Azure Portal and search for "App registrations".
Click New registration.
Name: Outlook MCP (or similar)
Supported account types: Accounts in this organizational directory only (Single tenant)
Redirect URI: Select Web and enter http://localhost/callback
Click Register.
Go to Authentication in the sidebar.
Under "Advanced settings", set Allow public client flows to Yes.
Click Save.
On the Overview page, copy:
Application (client) ID → This is your AZURE_CLIENT_ID
Directory (tenant) ID → This is your AZURE_TENANT_ID
Go to API permissions in the sidebar.
Click Add a permission -> Microsoft Graph -> Delegated permissions.
Add these permissions:
Mail.Read, Mail.ReadWrite, Mail.Send, Mail.Read.Shared, Mail.ReadWrite.Shared, Mail.Send.Shared
Calendars.Read, Calendars.ReadWrite
Contacts.Read, Contacts.ReadWrite
Tasks.Read, Tasks.ReadWrite
User.Read, MailboxSettings.Read
Files.Read.All, Files.ReadWrite.All
Sites.Read.All, Sites.ReadWrite.All
offline_access
Click Add permissions.
(Optional) If you are an admin, click Grant admin consent to suppress consent prompts for users.
Note: No client secret is required (PKCE auth flow).
Personal Microsoft accounts can also register apps in Azure:
Sign in to the Azure Portal with your personal Microsoft account (outlook.com, hotmail.com, etc.).
If prompted to create a directory, follow the steps to create a free Azure directory.
Follow the same steps as above for Business accounts.
When configuring, use Accounts in any organizational directory and personal Microsoft accounts for supported account types.
Variable | Required | Description |
| Yes | Your Azure AD application client ID |
| Yes | Your Azure AD directory (tenant) ID |
| No | Directory for saving large files (defaults to system temp) |
| No | Comma-separated extra directories save tools may write into when given an explicit |
| No | Default mailbox for the per-call 'mailbox' argument; empty = own mailbox. |
| No | Comma-separated shared mailboxes offered by |
The desktop extension (DXT) exposes only the mail settings above. The receipt/invoice-run behaviour below is configured by the calling process (e.g. a scheduled routine's MCP server config) via environment variables — it is intentionally not part of the extension settings UI:
Variable | Description |
| Directory where receipt/invoice PDFs are saved (falls back to work dir). Also passable per-call as |
| Optional JSON file of site-specific vendor rules (see below). Unset = generic heuristics only. If set but missing/invalid, receipt tools fail fast rather than silently degrade. |
| Comma-separated hosts |
| Receipt naming pattern (default: |
|
|
| Directory of the encrypted token store for headless runs (defaults to the built-in store) |
| Chrome/Chromium binary for |
RECEIPT_RULES_PATH)outlook_extract_receipt / outlook_collect_receipts work with zero configuration for
receipts issued via payment processors that put the vendor in the subject line
("Your receipt from Acme #1234"). For senders that need explicit mapping, or to
capture product labels, point RECEIPT_RULES_PATH at a JSON file
(see receipt-rules.example.json):
vendorSenders: [{ "pattern": "<case-insensitive regex on the from address>", "vendor": "<name>" }] — checked before the subject heuristic.
productLabels: ["<case-insensitive regex>", ...] — first match becomes productLabel; without rules it is null.
Five tools support autonomous expense-receipt collection (e.g. a scheduled monthly invoice run):
Tool | Purpose |
| Save an attachment's original bytes to a chosen path/filename. Auto-selects the |
| Fetch the PDF behind a billing link in an email body (fallback when a forward loses its attachment). HTTPS-only, allowlist-only (redirects included), content-type + magic-byte validated, 25 MB / 30 s bounded. |
| Compact structured summary of a receipt email (vendor, amount, currency, receipt/invoice numbers, product label, billing link, attachment ids) — never the 60 KB+ HTML body. |
| Render the sanitised email HTML to PDF via headless Chrome — audit-trail fallback for receipts with no attachment and no link (e.g. app-store order receipts). |
| One call per period: discovers each vendor's receipts by sender/subject/date across the whole mailbox, saves every PDF (attachment → link → rendered fallback), and returns a manifest plus |
outlook_create_draft additionally accepts attachmentPaths (absolute local file paths, ≤ 3 MB each) and returns the draft's webLink — it stages the email for review and never sends.
Receipt matching notes (v1.2):
A vendor rule's from and subjectContains combine as OR — either signal
matches a receipt, and each manifest entry reports matchedBy
(from, from-normalised, and/or subject).
Plus-addressed senders (invoice+statements+acct_...@stripe.com) match both
exactly and via a plus-stripped fallback: when an exact from finds nothing,
the collector retries on the base local part and keeps only messages whose
normalised sender matches, noting searchNote in the manifest.
periodStart/periodEnd (and outlook_search_emails' startDate/endDate)
accept bare dates: 2026-08-31 as an end covers the whole last day
instead of stopping at midnight.
outlook_download_attachment accepts saveToFile/destDir/fileName/onExisting
to write raw bytes server-side and return only {savedPath, size, sha256} —
use this for real invoice PDFs instead of inline base64.
Every mail, folder, and attachment tool — and every receipt tool
(collect_receipts, extract_receipt, save_attachment, render_email_pdf,
fetch_billing_pdf) — accepts an optional mailbox
argument (e.g. careers@yourcompany.com). Precedence: per-call mailbox →
the MCP_OUTLOOK_SHARED_MAILBOX setting → your own mailbox. Requirements:
Exchange Full Access delegation to the shared mailbox for the signed-in
user (Send As or Send on Behalf additionally governs how sends appear).
One styling note: signatures and font styling are always the signed-in
user's own — a send from a shared mailbox carries your personal signature,
so consider preserveUserStyling: false for shared sends.
The Mail.*.Shared delegated scopes — added in v1.3, so each user must
re-consent once: the interactive flow prompts automatically on next
sign-in; headless setups re-run npm run auth:bootstrap once.
Graph offers no delegated API that lists the mailboxes you hold Full Access to,
so discovery is candidate-based: outlook_list_shared_mailboxes probes the
addresses in the Known Shared Mailboxes setting
(MCP_OUTLOOK_KNOWN_MAILBOXES), the Shared Mailbox setting, and any
candidates you pass, then reports which ones actually open (with inbox
counts) and which are denied, missing, or malformed. Feed an accessible
address straight back as the mailbox argument.
Calendar tools stay on your own calendar in this release.
Seed tokens once, interactively: npm run auth:bootstrap (opens the browser PKCE flow and stores an encrypted refresh token).
Set MCP_OUTLOOK_AUTH_MODE=headless for the scheduled run. The server refreshes silently and never launches a browser; if re-consent is genuinely required it fails fast with an actionable error telling you to re-run the bootstrap.
Optionally set MCP_OUTLOOK_REFRESH_TOKEN_PATH to point the run at a specific token store directory.
When downloading large attachments or SharePoint files, the server automatically detects when the response would exceed the MCP response cap (~30k characters by default — the practical tool-output token budget; override with MCP_OUTLOOK_MAX_RESPONSE_CHARS) and saves the content to local files instead.
If MCP_OUTLOOK_WORK_DIR is set, large files are saved to this directory
If not set, files are saved to the system temp directory
Files are automatically named with timestamps to avoid conflicts
Old files are periodically cleaned up to manage disk space
Once installed, you can ask the AI assistant things like:
Email Management
"Show me my unread emails from this week"
"Find all emails from John about the project proposal"
"Send a reply to the last email from Sarah thanking her for the update"
"Draft an email to the team summarizing today's meeting"
Calendar
"What meetings do I have tomorrow?"
"Schedule a 30-minute call with Alex next Tuesday afternoon"
"Show me my availability for the rest of the week"
Attachments & SharePoint
"Download and summarize the PDF attachment from the latest email from Finance"
"Get the contents of this SharePoint link: [paste link]"
"What files were attached to emails from Legal this month?"
Receipts & Invoices
"Collect all my June receipts into my receipts folder and give me the manifest"
"Save the invoice PDF from the latest Acme receipt email as 'Acme 29Jun26 Invoice.pdf'"
"Draft an email to my accountant with last month's receipt PDFs attached — don't send it"
Office Document Processing
The server automatically parses:
PDF files: Extracts text content
Word documents (.docx): Extracts text content
PowerPoint (.pptx): Extracts slide text
Excel (.xlsx): Parses data into structured format
The server uses OAuth 2.0 with PKCE for secure authentication:
First run will open a browser for Microsoft authentication
Tokens are encrypted and stored locally (uses OS keychain if available, otherwise encrypted file storage)
Automatic token refresh for long-term usage
No sensitive data stored in plain text
The app requests these Microsoft Graph permissions:
Mail.Read, Mail.ReadWrite, Mail.Send - Email access
Mail.Read.Shared, Mail.ReadWrite.Shared, Mail.Send.Shared - Shared/delegated mailbox email access (v1.3)
Calendars.Read, Calendars.ReadWrite - Calendar access
Contacts.Read, Contacts.ReadWrite - Contact access
Tasks.Read, Tasks.ReadWrite - Task access
User.Read, MailboxSettings.Read - User profile
Files.Read.All, Files.ReadWrite.All - OneDrive/SharePoint files
Sites.Read.All, Sites.ReadWrite.All - SharePoint sites
offline_access - Refresh tokens
Problem: "Result exceeds maximum length" error
Solution: Ensure MCP_OUTLOOK_WORK_DIR is set and writable
Alternative: Files automatically save to system temp if work dir not configured
Problem: Authentication failures
Solution: Verify Azure AD app permissions and client ID
Reset: Clear stored tokens and re-authenticate
Problem: Cannot access SharePoint files
Solution: Ensure sharing links are valid and user has access permissions
Alternative: Use direct file ID access if available
outlook-mcp/
├── server/
│ ├── index.js # Main MCP server
│ ├── auth/ # Authentication management
│ ├── graph/ # Microsoft Graph API client
│ ├── schemas/ # MCP tool schemas
│ ├── tools/ # MCP tool implementations
│ │ ├── attachments/ # Attachment tools
│ │ ├── calendar/ # Calendar tools
│ │ ├── email/ # Email tools
│ │ ├── folders/ # Folder management
│ │ ├── receipts/ # Receipt/invoice-run tools
│ │ └── sharepoint/ # SharePoint tools
│ └── utils/ # Utility modules
└── package.jsonnpm test # Run all tests
npm run test:watch # Watch mode
npm run test:benchmark # Performance benchmarksnpm run test:graph # Test Graph API connectionIf this tool saved you time, consider supporting the development!
MIT License
Fork the repository
Create a feature branch
Make changes with tests
Submit a pull request
Add an attachment to an email draft
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email (draft) to add attachment to | |
| name | Yes | Name of the attachment file | |
| contentType | Yes | MIME type of the attachment | |
| contentBytes | Yes | Base64-encoded content of the attachment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Add an attachment' but does not mention whether it appends, overwrites, or any side effects. The mutation is implied but lacks detail like required draft state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It conveys the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 required parameters and no output schema, the description offers no context about return values, error conditions, or post-invocation behavior. It is too minimal for a state-modifying tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions, so the description adds no additional meaning. Baseline of 3 is appropriate as the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'add', the resource 'attachment', and the target context 'email draft'. It immediately distinguishes from sibling tools like outlook_download_attachment and outlook_list_attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., adding attachments during draft creation). It only states the action without context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archive an email (move to Archive folder)
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email to archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the tool moves the email to the Archive folder, indicating a non-destructive action. However, it lacks details on edge cases like archiving already archived emails 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately conveys the core functionality. It could be slightly more complete by mentioning reversibility or error handling, but it meets basic needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter with a description ('The ID of the email to archive'). The tool description adds no further semantic meaning beyond what the schema provides, yielding a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Archive an email' and specifies it moves to the Archive folder, distinguishing it from sibling tools like delete or move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like delete, move, or categorize. The description does not clarify the distinction between archiving and other email operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform bulk operations on multiple emails
| Name | Required | Description | Default |
|---|---|---|---|
| messageIds | Yes | Array of email IDs to process | |
| operation | Yes | The operation to perform on all emails | |
| operationData | No | Additional data for the operation (e.g., destinationFolderId for move) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any behavioral details beyond being a bulk operation. It does not disclose error handling (e.g., partial failures), rate limits, or whether operations are atomic. With no annotations, this is a significant gap for a potentially destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous information. It is well-structured but arguably too brief, sacrificing context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is incomplete. It does not explain the return value, error behavior, or limitations (e.g., maximum number of emails). More details are needed for a safe and effective tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters, including nested properties for operationData. The description adds no extra meaning beyond the schema, but the schema itself is clear, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform bulk operations on multiple emails' clearly indicates this tool is for batch processing, distinguishing it from sibling tools that handle single emails. However, it does not explicitly list the supported operations, though the schema provides an enum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this batch tool versus individual tools like delete_email or mark_as_read. There is no mention of trade-offs, such as efficiency or atomicity, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a recurrence pattern object
| Name | Required | Description | Default |
|---|---|---|---|
| patternType | Yes | Type of recurrence pattern | |
| interval | No | Interval between occurrences | |
| daysOfWeek | No | Days of the week for the pattern | |
| dayOfMonth | No | Day of the month | |
| monthOfYear | No | Month of the year | |
| index | No | Index for relative patterns (e.g., "first") | |
| rangeType | Yes | Type of recurrence range | |
| numberOfOccurrences | No | Number of occurrences | |
| rangeStartDate | No | Start date of the range | |
| rangeEndDate | No | End date of the range |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states it builds a pattern object, but does not disclose side effects, permissions, or whether it returns the object for later use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. Efficient but could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description is too sparse. It does not explain how parameters combine to form the recurrence object or what the output looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so baseline is 3. The description adds no additional meaning beyond the schema, but does not contradict it either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Build a recurrence pattern object' specifies the action and resource but is vague. Among siblings like 'outlook_create_recurrence_helper' and 'outlook_create_recurring_event', it doesn't differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'outlook_create_recurrence_helper'. No context on prerequisites or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply categories to an email
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email to categorize | |
| categories | No | List of category names to apply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a minimal description, the tool fails to disclose any behavioral traits. It doesn't indicate whether categories are added, replaced, or if they need to exist beforehand. No mention of permissions, side effects, or response details. This is a severe gap for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, conciseness should not come at the expense of useful information; the sentence is too brief to fully inform the agent. It could be restructured to include key details without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is notably incomplete. It lacks context on behavioral aspects like merging behavior, error conditions, and required permissions. This leaves the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (messageId and categories). The description adds no extra meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Apply categories to an email' clearly states the action and resource. It is specific enough to understand the tool's function and distinguishes it from sibling tools like 'outlook_flag_email' which applies a flag rather than categories. However, it could be more explicit about what categories are (e.g., tags/labels) and that it modifies the email's existing categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'outlook_flag_email' or 'outlook_archive_email'. It does not specify prerequisites or context, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check availability for users
| Name | Required | Description | Default |
|---|---|---|---|
| schedules | Yes | List of email addresses to check | |
| startTime | Yes | Start of the time range | |
| endTime | Yes | End of the time range | |
| availabilityViewInterval | No | Interval in minutes for availability view |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits like read-only nature, side effects, or any restrictions. With no annotations provided, the description carries full burden but fails to convey any behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words), but it sacrifices necessary detail. While brevity is valued, it should front-load essential information; here it is too sparse to be maximally helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, no annotations), the description lacks completeness. It does not explain return values, behavior, or how to interpret results, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description in the schema. The tool description adds no additional meaning beyond what the schema already provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check availability for users' clearly states the action (check) and resource (availability for users). It is specific and distinguishable from sibling tools like outlook_check_calendar_permissions and outlook_find_meeting_times, though a bit vague on the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as outlook_get_busy_times or outlook_find_meeting_times. There is no mention of prerequisites, exclusions, or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check permissions for a calendar
| Name | Required | Description | Default |
|---|---|---|---|
| calendarId | No | ID of the calendar to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral details such as error handling, authorization requirements, or return format. The description is minimal and fails to add value beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no unnecessary words. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description does not clarify what the output looks like (e.g., list of permissions, boolean) or what constitutes a 'permission check'. This is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'calendarId' is described in the schema as 'ID of the calendar to check'. The description does not add any additional meaning beyond the schema, and coverage is 100%, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and the resource ('permissions for a calendar'). It is distinct from sibling tools like outlook_check_availability or outlook_get_calendar_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The purpose is implied by the name, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an email draft without sending
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient email addresses | |
| subject | Yes | Email subject | |
| body | No | Email body content | |
| bodyType | No | Body content type | text |
| cc | No | CC recipients | |
| bcc | No | BCC recipients | |
| importance | No | Email importance level | normal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It only states creation without sending, omitting details like whether the draft is saved, permissions required, or return behavior. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence without fluff. It is appropriately concise, though it could include slightly more context without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 7 parameters and no output schema, the description is incomplete. It does not explain what happens to the draft (e.g., saved to drafts folder), any side effects, or return value, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema provides, repeating the concept but not enriching parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an email draft without sending' clearly states the action and resource, and explicitly distinguishes it from sending. Among siblings, 'outlook_send_email' exists, making the differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating drafts but lacks explicit guidance on when to use this tool versus alternatives like 'outlook_send_email'. No when-not-to-use or prerequisites are stated, relying on the tool name for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new calendar event in Outlook with optional Teams meeting integration
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | Event subject/title | |
| start | Yes | Event start date and time configuration | |
| end | Yes | Event end date and time configuration | |
| body | No | Event description | |
| location | No | Event location | |
| attendees | No | Attendee email addresses | |
| isOnlineMeeting | No | Whether to create this as a Teams meeting (default: false) | |
| onlineMeetingProvider | No | Online meeting provider (default: "teamsForBusiness") | |
| recurrence | No | Recurrence pattern for recurring meetings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It mentions 'optional Teams meeting integration' but does not detail side effects like sending invites, permissions required, or response format. Key behavioral traits for a write operation are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the core purpose. No unnecessary words or redundancy. Efficiently communicates the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, nested objects, no output schema, no annotations), the description is insufficient. It does not explain return values, success behavior, or provide context for handling recurrence. The tool requires more comprehensive guidance to be fully useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with detailed descriptions for each parameter. The description adds minimal value beyond the schema, only noting optional Teams meetings. Baseline score of 3 is appropriate as the schema already provides semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new calendar event in Outlook' with a specific verb and resource. It also mentions optional Teams meeting integration, which adds specificity. However, it does not explicitly differentiate from siblings like outlook_create_recurring_event, which is a closely related tool for recurring events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. For instance, when to use this vs outlook_create_recurring_event or outlook_update_event is not addressed. The description simply states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new email folder
| Name | Required | Description | Default |
|---|---|---|---|
| displayName | Yes | Name of the new folder | |
| parentFolderId | No | ID of parent folder (optional, creates at root level if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic creation action, omitting critical details like error handling for duplicate folder names, permission requirements, or confirmation of success. The description adds no value beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise and front-loaded. It could be slightly improved by mentioning the optional parent folder, but it remains efficient without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with well-documented parameters, the description is minimally complete. However, it lacks information on the return value or success confirmation, and no output schema is provided, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters have clear descriptions in the input schema. The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new email folder' clearly states the verb and resource, distinguishing it from sibling tools like outlook_rename_folder or outlook_list_folders. However, it does not specify that it can create subfolders via the optional parentFolderId parameter, which is a minor oversight.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, such as when to create a folder at root level vs as a subfolder. There are no prerequisites or exclusions mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helper to create a recurring event with simplified inputs
| Name | Required | Description | Default |
|---|---|---|---|
| eventTitle | Yes | Title of the event | |
| startDateTime | Yes | Start date and time | |
| endDateTime | Yes | End date and time | |
| recurrenceType | Yes | Type of recurrence (daily, weekly, etc.) | |
| endAfter | No | When to end the recurrence (date or occurrences) | |
| occurrences | No | Number of occurrences | |
| endDate | No | End date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'helper' without explaining what that entails (e.g., if it is an internal helper not intended for direct use). No mention of side effects, permissions, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise but lacking structure. It front-loads the purpose but provides no additional detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and sibling tools, the description is too brief. It does not explain 'simplified inputs' or how this helper relates to other tools, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description adds no extra meaning beyond the parameter names. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'create a recurring event' with a specific verb and resource. The term 'helper' and 'simplified inputs' provide some differentiation from sibling tools like outlook_create_recurring_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not clarify the difference from outlook_create_recurring_event or indicate when 'simplified inputs' is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a recurring calendar event
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | Event subject | |
| start | Yes | Start time | |
| end | Yes | End time | |
| recurrencePattern | Yes | Recurrence pattern object | |
| body | No | Event body content | |
| location | No | Event location | |
| attendees | No | List of attendees | |
| isOnlineMeeting | No | Whether to make this an online meeting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description gives no behavioral context: permissions required, side effects (e.g., sending invites), recurrence pattern constraints, or return value. The description is too sparse to inform an agent about the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It could benefit from a few more sentences to clarify recurrence scope or required fields without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 8 parameters, nested objects (start, end, recurrencePattern), and no output schema, the description is insufficient. It does not explain what is returned, how recurring series are handled, or how to set the recurrence pattern correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions for all 8 parameters. The tool description adds no extra semantic meaning beyond the schema, such as dateTime format expectations or recurrence pattern structure. Baseline score of 3 applies because schema handles parameter documentation without additional elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a recurring calendar event' clearly states the action (create) and the resource (recurring calendar event), distinguishing it from non-recurring event creation (e.g., outlook_create_event). However, it lacks specificity about the target calendar (user's default) or whether it creates a series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like outlook_create_event or outlook_schedule_online_meeting. The description does not mention prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an email (move to Deleted Items or permanently delete)
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email to delete | |
| permanentDelete | No | Whether to permanently delete (true) or move to Deleted Items (false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the behavioral choice between move to Deleted Items and permanent deletion via the permanentDelete parameter. However, no annotation provided and description lacks details on irreversibility, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys the action and two modes. No unnecessary words, front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal for a simple delete tool with 2 parameters and no output schema. Lacks details on return value, confirmation, or effect on attachments, but sufficient for straightforward use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 is appropriate. The description adds no additional insight beyond what the schema already explains for messageId and permanentDelete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an email, with explicit options to move to Deleted Items or permanently delete. It distinguishes from sibling tools like archive or move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as archive or move. Does not mention scenarios where use is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a calendar event
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | The ID of the event to delete |
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 merely states 'Delete a calendar event' without revealing whether deletion is permanent, affects attendees, or requires special permissions. The description adds no behavioral context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the purpose. It is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and no output schema, the description is somewhat complete but lacks critical context: whether it deletes recurring events (single occurrence vs. series), reversibility, and error conditions. It does not compensate for the missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'eventId' has a schema description that clearly explains its purpose. Schema coverage is 100%, meeting the baseline. The tool description does not add further meaning, such as how to obtain the event ID, but the schema alone is adequate for a simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a calendar event' is a specific verb+resource pair that clearly states the action and object. It effectively distinguishes from sibling tools like outlook_delete_email (deletes email) and outlook_update_event (modifies event).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like outlook_update_event or outlook_respond_to_invite. There is no mention of prerequisites (e.g., event existence), consequences (e.g., permanence), or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a specific email attachment
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email containing the attachment | |
| attachmentId | Yes | The ID of the attachment to download | |
| includeContent | No | Whether to include the file content | |
| decodeContent | No | Whether to decode Base64 content to readable format (text files) or provide summary (binary files) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'download', implying a read operation but not explicitly confirming non-destructiveness or side effects. It fails to disclose what happens to the attachment (e.g., stored in memory, returned as binary), leaving behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core action efficiently. It is well-structured and front-loaded, though it could benefit from a brief elaboration on usage without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and 4 parameters, the description is incomplete. It does not explain what the tool returns (e.g., file content, URL) or how to interpret the response, leaving the agent without critical output context for a download operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the description does not need to add much. However, it adds no extra meaning beyond the schema, such as clarifying the role of 'includeContent' or 'decodeContent' defaults, resulting in adequate but not enhanced semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Download' and the resource 'email attachment', clearly indicating the action and object. It distinguishes from sibling tools like 'outlook_add_attachment' (add) and 'outlook_list_attachments' (list), but does not explicitly differentiate from other download-like tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as 'outlook_list_attachments' to get attachment IDs first. There are no prerequisites or conditions mentioned, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find optimal meeting times for attendees
| Name | Required | Description | Default |
|---|---|---|---|
| attendees | Yes | List of attendees to check availability for | |
| timeConstraint | No | Time range to search within | |
| meetingDuration | No | Duration of the meeting (ISO 8601 duration) | |
| maxCandidates | No | Maximum number of time slots to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not state whether the tool is read-only, if it requires specific permissions, or what side effects (if any) occur. The agent is left to infer that it only retrieves suggested times.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the key action. It is efficiently brief, though it could expand slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value (no output schema), and nested objects like timeConstraint are not explained beyond schema. For a tool with 4 parameters and nested objects, more context is needed to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all parameters are documented. The description adds no extra meaning beyond the schema, thus baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'find' and the resource 'optimal meeting times for attendees', making the purpose immediately understandable. However, it does not differentiate from sibling tools like outlook_check_availability or outlook_get_busy_times, which also deal with attendee availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., outlook_get_busy_times or outlook_schedule_online_meeting). It also fails to mention prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flag or unflag an email for follow-up
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email to flag | |
| flagStatus | No | The flag status to set | flagged |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'flag or unflag', lacking details on side effects, reversibility, or concurrency. Acceptable for a simple toggle but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Front-loaded with action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple flag action with good schema coverage, the description is sufficient. Could mention default flagStatus behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions; description adds no extra meaning. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (flag/unflag) and resource (email for follow-up), distinguishing it from siblings like mark_as_read or categorize_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for toggling flag status, but provides no explicit guidance on when to use vs alternatives like categorize_email or mark_as_read, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forward an existing email to new recipients
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email to forward | |
| to | Yes | Recipient email addresses for forwarding | |
| body | No | Additional message body for the forward | |
| bodyType | No | Body content type | text |
| comment | No | Optional comment for the forward |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action but fails to mention whether the forward is sent immediately or saved as draft, if it modifies the original email, or if special permissions are needed. This is insufficient for a write operation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but somewhat terse. It could be restructured to include more information without being verbose, such as mentioning the action's outcome.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters and no output schema, the description should provide more context about the forwarding process (e.g., does it create a draft or send? Are there constraints on recipients?). The minimal description leaves gaps, especially given the complexity of email forwarding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters have descriptions in the input schema (100% coverage), so the description does not need to add much. However, the description adds no extra semantics beyond what the schema provides, such as how 'body' interacts with the original email content. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Forward' and the resources 'existing email' and 'new recipients'. It effectively distinguishes this tool from siblings like outlook_reply_to_email (which replies to original sender) and outlook_send_email (which composes a new email).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies basic usage (forwarding an email) but does not provide any explicit guidance on when to use this tool versus alternatives like reply or reply-all. There is no mention of limitations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get busy times for users
| Name | Required | Description | Default |
|---|---|---|---|
| schedules | Yes | List of email addresses to check | |
| startTime | Yes | Start of the time range | |
| endTime | Yes | End of the time range | |
| availabilityViewInterval | No | Interval in minutes for availability view |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose any behavioral traits such as read-only status, required permissions, or side effects. The word 'Get' implies read-only, but this is implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (4 words), but it is appropriately sized for a minimal definition. However, it could be expanded without becoming verbose to improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values or behavior. It does not, leaving the agent without crucial context about what the tool returns or how to interpret the busy times.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters. The description adds no extra meaning beyond what the schema already provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get busy times for users', which identifies the action and resource. However, it lacks specificity (e.g., what 'busy times' entails) and does not distinguish from the similar sibling tool 'outlook_check_availability'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'outlook_check_availability'. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a view of a calendar for a specific time range
| Name | Required | Description | Default |
|---|---|---|---|
| startDateTime | Yes | Start of the time range | |
| endDateTime | Yes | End of the time range | |
| calendarId | No | ID of the calendar to view | |
| top | No | Number of events to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like what the view contains (events?), pagination (the 'top' parameter hints at it), and whether recurring events are expanded. It only states 'get a view', which is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no unnecessary words. It is appropriately concise, though it could benefit from additional details without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameters, the description fails to explain what the tool returns (events? with what details?), lacks information on output or behavior, and doesn't differentiate from sibling tools. It is too minimal given the complexity and sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 mentions 'specific time range' which aligns with startDateTime and endDateTime, but adds no new meaning beyond the schema. No additional parameter context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a view of a calendar for a time range. However, it does not distinguish this tool from 'outlook_list_events', which likely also retrieves events from a calendar, creating potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like 'outlook_get_event' or 'outlook_list_events'. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific email
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email message to retrieve | |
| truncate | No | Truncate long email bodies (default: true) | |
| maxLength | No | Maximum length for truncated body (default: 1000) | |
| format | No | Format of the body content (default: text) | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get detailed information' but does not explain what 'detailed' includes (e.g., headers, body, attachments), whether it marks the email as read, or any side effects. The description is too sparse to inform safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-informative for a tool with 4 parameters. It lacks any structure (e.g., bullet points or examples) and does not front-load critical details like which parameter is required. Every sentence should add value, but this does not earn its place for a parameterized tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain return format or content. It only says 'detailed information'—vague. The agent needs to know if the response includes body, attachments, or headers. Also, truncation parameters are not contextualized. The description is incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage—each parameter has a description. The description adds no additional meaning beyond the schema. It does not clarify defaults (truncate=true, maxLength=1000) or suggest when to adjust them. Baseline 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a specific email' clearly states the verb (get) and resource (detailed email info). However, it does not differentiate from siblings like outlook_get_event or outlook_get_folder_stats, which also fetch details. The tool retrieves a single email, which is distinct from list/search, but not explicitly noted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as outlook_list_emails or outlook_search_emails. There is no mention of prerequisites (e.g., needing a messageId) or when not to use it (e.g., for bulk operations). The description leaves the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific calendar event
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | The ID of the event to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'Get' with no mention of read-only nature, error handling for missing events, or required permissions. The description adds minimal value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but arguably under-specified. It is front-loaded but does not earn its place by providing sufficient context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation with one required parameter and no output schema, the description lacks information about the return value (the event object) and does not clarify that this is a read operation unlike the mutation siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add extra meaning to the eventId parameter beyond what the schema provides ('The ID of the event to retrieve').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a specific calendar event', which is a specific verb-resource pair. However, it does not explicitly differentiate from siblings like outlook_get_calendar_view or outlook_list_events, which also retrieve events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It does not mention that the event ID must be obtained from a prior list/search, nor does it indicate that this tool is for single event retrieval by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics for a specific folder
| Name | Required | Description | Default |
|---|---|---|---|
| folderId | Yes | ID of the folder to get stats for | |
| includeSubfolders | No | Include statistics for subfolders |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'get statistics', not explaining that it is a read-only operation, what statistics are included, or any side effects. Incomplete for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, but it sacrifices helpful detail. While front-loaded, it is borderline under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. The description does not explain return values or format, leaving the agent with insufficient context to use the results. Lack of statistics type (counts, sizes, etc.) is a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already described in the schema. The description adds no new parameter information beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb and resource: 'Get statistics for a specific folder'. It is unambiguous and differentiates from most sibling tools, though lacking specificity on what statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like outlook_list_folders. No hints on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all attachments for a specific email
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email to list attachments for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'list attachments' without mentioning if it returns metadata or content, authorization requirements, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but lacks structure and important details. It is not excessively long, but conciseness should not come at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description should at least hint at what the list output contains (e.g., names, sizes). It does not, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the single parameter 'messageId' is already described in the schema. The description adds no extra meaning beyond the schema, which is adequate for a simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists attachments for a specific email. It identifies verb ('list') and resource ('attachments'), but does not distinguish from sibling tools like outlook_scan_attachments, which may also list attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., outlook_scan_attachments). No prerequisites or context provided, such as the need for a valid messageId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available calendars
| Name | Required | Description | Default |
|---|---|---|---|
| includeSharedCalendars | No | Whether to include shared calendars | |
| top | No | Number of calendars to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'List available calendars' without mentioning side effects, authentication needs, or what 'available' means (e.g., own vs shared).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks output schema, so the agent does not know the return format. The description omits what information each calendar entry contains (ID, name, etc.), leading to incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes both parameters (includeSharedCalendars and top) with 100% coverage. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List available calendars' which is a specific verb and resource. However, it does not distinguish from sibling tools like 'outlook_list_events' or 'outlook_get_calendar_view', which list different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or any context for its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List emails from Outlook inbox or specified folder
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Folder to list emails from (default: inbox) | inbox |
| limit | No | Maximum number of emails to return | |
| filter | No | OData filter query for emails |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but lacks details on pagination, sorting, read-only nature, or output format. The brevity leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant information. Perfectly concise for the functional requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 3 parameters, and no annotations, the description is too minimal. It omits return format, pagination behavior, and typical use context, leaving agents underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description reinforces the folder parameter's default but adds no new meaning beyond schema, not covering filter format (OData).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'emails' with a specific location ('Outlook inbox or specified folder'), effectively distinguishing it from sibling tools like outlook_search_emails or outlook_get_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., outlook_search_emails for advanced filtering). It fails to specify any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List calendar events from Outlook
| Name | Required | Description | Default |
|---|---|---|---|
| startDateTime | No | Start date/time in ISO 8601 format | |
| endDateTime | No | End date/time in ISO 8601 format | |
| limit | No | Maximum number of events to return | |
| calendar | No | Calendar ID (default: primary calendar) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only says 'list', implying read-only, but omits details like ordering, pagination, or whether it returns full event objects. The schema indicates a date range, but the description does not disclose behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. It is efficient but lacks structure or front-loading of key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description should explain the return format or behavior. It lacks completeness, e.g., not mentioning if results are paginated or what event details are included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description adds no extra meaning beyond the schema, meeting the baseline. For example, startDateTime is already described in the schema as ISO 8601 format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List calendar events from Outlook', specifying the verb and resource. However, it does not differentiate from sibling tools like outlook_get_calendar_view or outlook_get_event, which also retrieve calendar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. There are many sibling calendar tools (e.g., outlook_get_event, outlook_find_meeting_times), but the description provides no context for choosing this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all email folders
| Name | Required | Description | Default |
|---|---|---|---|
| includeHidden | No | Include hidden folders | |
| includeChildFolders | No | Include nested child folders | |
| top | No | Maximum number of folders to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states 'List all email folders,' lacking details on filtering (hidden/child), limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one short sentence), but at the cost of missing necessary context; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no output schema, the description should explain filtering options and output format; it only says 'List all email folders,' which is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so baseline is 3; the tool description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all email folders' clearly states the verb (list) and resource (email folders), but it does not differentiate from sibling tools like outlook_create_folder or outlook_get_folder_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no mention of context or preconditions for using the parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark an email as read or unread
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email to mark | |
| isRead | No | Whether to mark as read (true) or unread (false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral details. It states the basic action but does not disclose side effects (e.g., whether it triggers notifications), prerequisites (e.g., message must exist), or return behavior. Adequate for a simple toggle but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero wasted words. Every element is necessary and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters, no output schema, and no nested objects, the description adequately conveys the core function. It could mention the response (e.g., success status) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (messageId, isRead) have descriptions in the schema with 100% coverage. The tool description adds little new meaning beyond 'mark as read or unread', which mirrors the isRead description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark an email as read or unread' clearly states the action (mark) and the resource (email) with a specific range of states (read/unread). This distinguishes it from sibling tools like move_email or flag_email, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives, such as using outlook_get_email to check status first or which scenarios require marking as unread. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move an email to a different folder
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email to move | |
| destinationFolderId | Yes | The ID of the destination folder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action 'move' but does not detail side effects (e.g., permission requirements, whether the email is removed from the source folder, or rate limits). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the core function efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with two required parameters and no output schema, the description lacks behavioral context (e.g., what happens to the original folder after move). Basic completeness is achieved, but more details would improve agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The tool description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate since the schema already explains the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and the resource ('an email to a different folder'). It distinguishes itself from sibling tools like 'outlook_archive_email' and 'outlook_delete_email' by specifying the move operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., archive, copy, delete) or when not to use it. Given the large number of sibling tools, explicit usage context would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename an existing email folder
| Name | Required | Description | Default |
|---|---|---|---|
| folderId | Yes | ID of the folder to rename | |
| newDisplayName | Yes | New name for the folder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, permissions, or limitations. It only states the action, omitting details like allowed name length or impact on folder structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, for a simple action, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the basic purpose but lacks behavioral context (e.g., success indicator, error conditions). No output schema, so return info is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename') and resource ('existing email folder'), distinguishing it from sibling tools like create_folder or move_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites (e.g., folder existence), or when not to use it. Alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to all recipients of an existing email
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email to reply all to | |
| body | No | Reply message body | |
| bodyType | No | Body content type | text |
| comment | No | Optional comment for the reply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details such as whether the reply is sent immediately, permission requirements, or effects on the original email. The description is too brief to compensate for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose. It is concise but could be slightly expanded for context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 lacks completeness. It does not explain return values, threading behavior, or when the action takes effect, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond the schema. Baseline of 3 is appropriate as the schema adequately describes each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Reply to all recipients of an existing email'. This distinguishes it from the sibling outlook_reply_to_email which replies only to the sender.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like outlook_reply_to_email. The description relies on the name for differentiation, which may be insufficient for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to an existing email
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the email to reply to | |
| body | No | Reply message body | |
| bodyType | No | Body content type | text |
| comment | No | Optional comment for the reply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic action with no disclosure of side effects, required permissions, threading behavior, or whether the reply is sent immediately. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. However, it could be slightly expanded to include essential context without adding waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description is too minimal. It lacks information on how the reply is composed, whether attachments are supported, and the behavior of the comment parameter. The agent would need to infer details from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters having descriptions. The description does not add meaning beyond the schema. Baseline 3 is appropriate as the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reply to an existing email' clearly states the action (reply) and the resource (existing email). It is specific enough to distinguish from siblings like outlook_reply_all and outlook_forward_email, which are different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as outlook_reply_all or outlook_forward_email. The description does not mention the context or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Respond to a meeting invitation
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | The ID of the event to respond to | |
| response | Yes | Response type | |
| comment | No | Optional comment | |
| sendResponse | No | Whether to send a response email (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Respond to a meeting invitation'. It fails to disclose side effects (e.g., sending a response email), default behavior (sendResponse defaults to true), or required permissions. The tool's mutation effect is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core action without unnecessary words. However, it is so brief that it omits important context; one could argue it is under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description is too sparse. It does not explain that the eventId must belong to an invitation, that response sends a reply, or what happens after a response. More detail is needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond what the schema already provides for each parameter. The enum values for 'response' are clear from the schema, and the comment parameter is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Respond to a meeting invitation' clearly states the verb (respond) and resource (meeting invitation), distinguishing it from sibling tools like outlook_create_event or outlook_update_event. It identifies a specific action not covered by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as outlook_update_event or outlook_create_event. It does not specify that this is for invitations received from others, nor does it mention prerequisites like needing an invitation event ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan emails for large or suspicious attachments
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Folder to scan (default: inbox) | inbox |
| maxSizeMB | No | Maximum attachment size in MB to flag as large | |
| suspiciousTypes | No | File extensions to flag as suspicious | |
| limit | No | Maximum number of emails to scan | |
| daysBack | No | How many days back to scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the tool is read-only, has side effects, requires authentication, or has rate limits, leaving critical behavioral traits unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. While it could include more detail, it avoids verbosity and is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the return format or what 'scan' produces (e.g., list of emails, actions taken). With no output schema, the agent lacks a complete picture of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans emails for large or suspicious attachments, which distinguishes it from listing or downloading attachments. However, it does not explicitly differentiate from sibling tools like 'outlook_list_attachments'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it specify prerequisites or contraindications. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule an online meeting (Teams/Skype)
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | Meeting subject | |
| startTime | Yes | Start time | |
| endTime | Yes | End time | |
| attendees | No | List of attendees | |
| meetingProvider | No | Online meeting provider |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the purpose but omits important details: permissions required, whether invitations are sent, what happens if no provider is selected, or side effects of scheduling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key action and resource. It is concise without being wasteful, though slightly more detail could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters, no output schema, and no annotations, the description lacks completeness. It does not explain parameter formats, provider options, or return value, leaving gaps for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already described. The description adds no additional meaning beyond parameter names and schema comments. Baseline score of 3 is appropriate as no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Schedule an online meeting (Teams/Skype)' clearly identifies the tool's action (schedule) and resource (online meeting). It distinguishes from siblings like outlook_create_event by specifying online meeting and provider, though it doesn't explicitly differentiate from other scheduling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like outlook_create_event. There is no mention of prerequisites, when-not scenarios, or which meeting provider to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search emails across all folders with advanced filters for analysis
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text search query across email content | |
| subject | No | Search emails with specific subject text | |
| from | No | Filter emails from specific sender | |
| startDate | No | Start date for email search (ISO 8601 format) | |
| endDate | No | End date for email search (ISO 8601 format) | |
| folders | No | Specific folders to search in | |
| limit | No | Maximum number of emails to return. Default: 25. NOTE: If includeBody is true, this is strictly capped at 5 to prevent context overflow. | |
| includeBody | No | Include full email body content for analysis. WARNING: Setting this to true restricts the result limit to 5. | |
| truncate | No | Truncate long email bodies (default: true) | |
| maxLength | No | Maximum length for truncated body (default: 1000) | |
| format | No | Format of the body content (default: text) | text |
| orderBy | No | Sort order (e.g., "receivedDateTime desc") | receivedDateTime desc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits, but it only states the basic purpose. It does not mention side effects, performance, or behavior with large results. The schema contains useful notes (e.g., limit capping with includeBody), but these are not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose without redundancy. It is appropriately front-loaded and avoids unnecessary detail, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters and no output schema, the description is too brief. It does not explain the return format, pagination, or how 'advanced filters' are applied. The schema covers details, but the description alone is insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, the baseline is 3. The description does not add any extra meaning beyond the schema's parameter descriptions. It does not compensate for the lack of enums or nested objects, but it also does not mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 emails across all folders with advanced filters for analysis'. It specifies the verb (search) and resource (emails), and implies differentiation from simpler list tools like 'outlook_list_emails' by mentioning 'advanced filters'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool vs alternatives. It hints at advanced use ('advanced filters') but does not define scenarios, exclusions, or mention siblings like 'outlook_list_emails' or 'outlook_get_email'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an email through Outlook
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient email addresses | |
| subject | Yes | Email subject | |
| body | Yes | Email body content | |
| bodyType | No | Body content type | text |
| cc | No | CC recipients | |
| bcc | No | BCC recipients | |
| preserveUserStyling | No | Apply user's default Outlook styling, font preferences, and signature |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavior. It only says 'Send an email' without mentioning side effects (e.g., immediate sending), required permissions, or error responses. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure or additional detail. It is not verbose, but could be more informative within the same length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should explain return values or confirmation. It does not mention success/failure indications, rate limits, or what happens after sending. Incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters described). The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send an email through Outlook' is clear and specific. It distinguishes from sibling tools like 'outlook_create_draft' or 'outlook_forward_email' by indicating direct sending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention when to use this instead of 'outlook_create_draft' or 'outlook_reply_to_email'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing calendar event
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | The ID of the event to update | |
| subject | No | New subject | |
| body | No | New body content | |
| location | No | New location | |
| start | No | New start time | |
| end | No | New end time | |
| attendees | No | New list of attendees |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose behavioral traits such as effect on existing data, error handling, or whether partial updates are supported. The description only restates the function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise and front-loaded with the core action, though it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 7 parameters (including nested objects) and no output schema, the description is far too minimal. It does not explain how parameters interact, expected formats, or what the function returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so baseline is 3. The tool description adds no additional semantic context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('existing calendar event'), making the tool's purpose unambiguous. It is specific and distinguishes from sibling tools like 'create_event'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., creating vs. updating events). There is no mention of prerequisites or scenarios where this tool is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate event start and end times
| Name | Required | Description | Default |
|---|---|---|---|
| start | Yes | Start time to validate | |
| end | Yes | End time to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states 'validate,' implying a read-only check, but does not confirm side effects, error handling, or return behavior. This lack of detail fails to inform the agent about consequences or output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it is somewhat under-specified, but conciseness is still a strength given the minimal text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what the validation returns (e.g., boolean, errors). It does not. With many sibling tools, the context of when to validate is unclear. The description is incomplete for understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with basic descriptions (e.g., 'Start time to validate'). Since schema description coverage is 100%, the description adds no extra meaning beyond what the schema already provides. The description does not clarify format requirements or constraints for dateTime or timeZone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Validate event start and end times,' which identifies the action and resource. However, it does not specify what validation entails (e.g., format, logical consistency), making it somewhat vague. Without distinguishing from siblings like outlook_check_availability or outlook_find_meeting_times, the purpose is only partially clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as before creating or updating an event. No exclusions or context are provided, leaving the agent without clear direction on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1outlook_add_attachmentoutlook_archive_emailoutlook_batch_process_emailsoutlook_build_recurrence_patternoutlook_categorize_emailoutlook_check_availabilityoutlook_check_calendar_permissionsoutlook_create_draftoutlook_create_eventoutlook_create_folderoutlook_create_recurrence_helperoutlook_create_recurring_eventoutlook_delete_emailoutlook_delete_eventoutlook_download_attachmentoutlook_find_meeting_timesoutlook_flag_emailoutlook_forward_emailoutlook_get_busy_timesoutlook_get_calendar_viewoutlook_get_emailoutlook_get_eventoutlook_get_folder_statsoutlook_get_sharepoint_fileoutlook_list_attachmentsoutlook_list_calendarsoutlook_list_emailsoutlook_list_eventsoutlook_list_foldersoutlook_list_sharepoint_filesoutlook_mark_as_readoutlook_move_emailoutlook_rename_folderoutlook_reply_alloutlook_reply_to_emailoutlook_resolve_sharepoint_linkoutlook_respond_to_inviteoutlook_scan_attachmentsoutlook_schedule_online_meetingoutlook_search_emailsoutlook_send_emailoutlook_update_eventoutlook_validate_event_datetimesScored across 43 tools
Most tools have clearly distinct purposes, but there are overlapping clusters: outlook_check_availability, outlook_find_meeting_times, and outlook_get_busy_times all deal with availability; outlook_create_recurring_event, outlook_create_recurrence_helper, and outlook_build_recurrence_pattern are related to recurrence. These may cause some confusion for an agent.
All tools follow a consistent outlook_verb_noun pattern (e.g., outlook_add_attachment, outlook_create_event). Naming is uniform and predictable, making it easy for an agent to infer functionality.
43 tools is on the higher side, but it covers a broad domain including email, calendar, folders, and SharePoint file operations. Each tool serves a specific function, so the count is reasonable for the scope, though slightly heavy.
The tool set provides comprehensive coverage for email lifecycle (create, send, reply, forward, move, delete, archive, flag, categorize, search) and calendar management (create, update, delete events, schedule meetings, check availability, manage permissions, recurrence). Additional tools for folder management, attachments, and SharePoint files fill potential gaps.
Manage Microsoft 365 email, calendar, contacts and inbox rules via the Graph API with OAuth 2.0.
GDPR-compliant calendar access for AI assistants: read, create, edit, RSVP. Google, MS 365, Apple.
Connect any mailbox to Claude, ChatGPT & AI: read, send, reply, schedule & search emails.
Read email/chat conversations, messages, contacts and teams; draft, send and update threads.
