mariana-outlook-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clear, distinct purposes within their domains, but 'calendar_search' and 'calendar_list' both retrieve calendar events and could be confused. The soft-delete tools for mail and calendar share a similar pattern but are separated by domain.
Naming Consistency5/5
All tools follow a consistent 'domain_action' pattern, using lowercase with underscores (e.g., outlook_read, calendar_create, contacts_search). The use of compound actions like 'flag_delete' and 'move_to_delete' still maintains a uniform style without mixing conventions.
Tool Count4/5
With 21 tools, the server is slightly above the typical well-scoped range, but the breadth is justified by covering mail, calendar, contacts, and authentication. The tools are not excessively fragmented for the wide scope.
Completeness3/5
Mail and calendar have decent coverage, but contacts only support search and list with no create/update/delete operations. The lack of hard delete for messages/events and exclusion of sending email are notable gaps that limit full lifecycle management.
Average 3.8/5 across 21 of 21 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Get full details' which implies a read operation, but it does not disclose what 'full details' includes, whether authentication is required, or any other behavioral context. This is a minimal description that adds little 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded with the action and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one required parameter and no output schema, the description is minimally sufficient. However, the phrase 'full details' is vague and does not explain what information will be returned, which would be especially helpful given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both 'account' and 'event_id' having descriptions. The tool description itself adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full details of a specific calendar event', distinguishing it from siblings like calendar_list or calendar_search by emphasizing 'specific'. However, it does not explicitly name alternatives, so it falls short of the highest bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as calendar_search or calendar_list. The context is only implied by the word 'specific', but there are no explicit conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It only says 'List', which implicitly indicates a read operation but does not elaborate on any behavioral traits such as default account handling, pagination, or potential rate limits. The description adds little beyond the basic verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It communicates the core purpose and an optional filter in an efficient, front-loaded manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with all parameters documented in the schema, but the description doesn't mention return format or how it differs from contacts_search. Given the absence of an output schema and annotations, the description is minimally viable but leaves some gaps around expected behavior and alternative usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the parameters, each with a clear description. The description itself repeats the 'filtered by organization or name' notion already present in the schema, adding no new semantic value. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Outlook contacts, with optional filtering. This is a specific verb+resource combination. However, it does not explicitly distinguish itself from the sibling tool contacts_search, which likely performs a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like contacts_search. It only mentions optional filtering, but gives no contextual or exclusionary cues. Sibling tool names suggest overlapping functionality, yet no differentiation is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It states the action but does not disclose matching behavior (partial vs exact), case sensitivity, output format, pagination, or account handling. This is thin for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the key action and target. No filler, every word earns its place. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema and no annotations, the description omits return value expectations, search scoping, and how it differs from contacts_list. It is minimally adequate but leaves important completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: all three parameters (query, account, max_results) have clear descriptions. The tool description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' and identifies the resource 'Outlook contacts' with searchable fields (name, email, phone). This clearly distinguishes it from sibling contact_list (which lists) and outlook_search (which may cover broader Outlook items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding contacts by query but does not provide explicit when-to-use or alternative guidance. With sibling contact_list available, the lack of a note about search vs list is a gap, but the intended use is reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the useful detail that KQL syntax is supported, but it does not disclose whether the operation is read-only, what the return format is, any pagination behavior, or authentication requirements. For a tool with no annotation safety hints, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose ('Search Outlook messages') and includes a concrete example of KQL syntax. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description should explain what the search returns and any behavioral caveats. It does not mention the result format, ordering, folder scope, or error conditions. The KQL note is helpful, but the description remains too minimal to be fully contextual for a search tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description's KQL example ('from:name subject:topic') adds marginal reinforcement to the query parameter description already present in the schema, but does not introduce new semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Outlook messages' with a specific verb and resource, distinguishing it from sibling tools like calendar_search and contacts_search by targeting Outlook messages specifically. The mention of KQL syntax also adds clarifying detail, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching Outlook messages but does not explicitly state when to use it over alternatives or mention exclusions. While the resource is clear, there is no direct comparison to outlook_read (which reads a single message) or other search tools, leaving the guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only reveals the name-not-ID constraint, but does not mention whether the category must already exist, whether applying replaces or adds to existing categories, error handling, or side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the primary action and key constraint. No filler or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient to understand the core operation and parameter format, but it lacks behavioral context such as idempotency, dependency on existing categories, or what happens with invalid message IDs. Given there is no output schema or annotations, this leaves some gaps for a mutation tool. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description adds minimal value beyond reinforcing that category is a name and that message_ids is plural. The account parameter is already explained in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply') with a clear resource ('category to one or more Outlook messages') and adds a critical differentiator: 'by category NAME, not ID.' This distinguishes it from sibling tools like outlook_create_category and outlook_remove_category, and the name/ID note disambiguates from potential ID-based operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to apply a category to messages) but does not explicitly state when to use this tool versus alternatives, such as outlook_create_rule for automating categorization or outlook_remove_category for removing. There are no explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the mutation action without mentioning idempotency, error conditions, permissions, side effects, or return values. The 'Gmail-labels equivalent' hints at typical label behavior but does not substantively explain what happens during creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly crafted sentence that states the action and provides a useful analogy, with no filler or redundancy. It is front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is minimal. While it correctly identifies the purpose, it omits practical details such as what the agent should expect as a return value, whether the operation is idempotent, and how it integrates with related tools like outlook_list_categories. However, the schema covers parameter semantics, making the description sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (name, account, color_preset), so the schema coverage is 100%. The tool description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Create a new Outlook category.' The parenthetical '(the Gmail-labels equivalent)' provides helpful context and distinguishes it from sibling tools like outlook_apply_category and outlook_remove_category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the action verb 'create' – one would use this tool to make a new category. However, there is no explicit guidance on when to prefer this over alternatives, nor any exclusions or prerequisites, such as ensuring the category doesn't already exist or that authentication is handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'List', which implies a read-only operation, but it does not explicitly state that there are no side effects, nor does it mention any limitations, defaults, or what happens if the account is not found. No behavioral details beyond the action itself are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is immediately understandable, front-loaded with the verb and resource. It contains no filler or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema or annotations. The description tells what it does but does not describe the return format, the structure of categories, or any edge-case behavior. This is a noticeable gap for an agent that needs to know what to expect from the response. However, given the tool's minimal complexity, it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'account', with a clear description. The tool description adds no new meaning about the parameter, so the baseline of 3 applies. It neither enhances nor detracts from the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'Outlook categories', and adds a helpful analogy 'the Gmail-labels equivalent' that distinguishes it from sibling tools like outlook_create_category or outlook_list_folders. It conveys exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it lists categories, but it does not explicitly mention when to use this tool versus alternatives or provide any exclusions. While the analogy to Gmail labels gives context, it lacks direct guidance on choosing this over sibling tools like outlook_list_folders or outlook_create_category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states only the action 'List' with no details on return format, authentication needs, permissions, or whether the listing includes subfolders. It does not contradict any annotations (since none exist), but it fails to reveal important behavioral characteristics beyond the minimal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that immediately communicates the tool's function. There is no redundancy or filler, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with one optional parameter and no output schema, the description is minimally adequate but lacks details about the return value or any side effects. It would be more complete if it mentioned what the response contains (e.g., folder names, paths) or any caveats like authentication requirements, but the simplicity of the tool partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with a clear description for the 'account' parameter. The description's phrase 'for an account' aligns with the parameter but adds no extra meaning. Since schema coverage is high, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'Outlook mail folders', with scope 'for an account'. This distinguishes it from sibling tools like outlook_read, outlook_search, and calendar_list, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an account's folders need to be listed, but provides no explicit guidance on when to choose this tool over alternatives. There are no exclusion criteria or mention of related tools like outlook_read for reading messages or calendar_list for calendar folders, leaving usage somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It adds a useful behavioral detail: times are returned in UTC. It does not explicitly state that this is a read-only operation, nor does it describe pagination, response structure, or ordering, but the verb 'list' implies a non-destructive read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and every word earns its place: it states the action, the resource, the timeframe, and the timezone. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional parameters, no nested objects) and full schema coverage, the description is reasonably complete. Without an output schema, it mentions the return type (calendar events) and the timezone (UTC). It could be more explicit about returning event details, but for a simple list tool, it provides adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (account and days_ahead). The description adds no additional meaning about these parameters beyond the schema's own descriptions, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'List upcoming calendar events'. It adds a timezone detail ('Times are returned in UTC') that helps specify the output. However, it does not distinguish this list tool from its sibling tools like calendar_search or calendar_get, which likely overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need upcoming events, but it gives no explicit guidance on when to prefer this tool over alternatives such as calendar_search or calendar_get. There are no exclusions or alternative tool references, leaving the agent to infer the intended use case from the tool name and the word 'upcoming'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that the tool returns full message content as plain text, which is helpful, but does not mention side effects, permissions, or whether reading marks the message as read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and efficiently communicates the tool's purpose and return format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and return format but lacks guidance on preconditions, alternative usage, or error behavior, so it is adequate but not complete for a tool with no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters with 100% coverage, and the description adds no additional parameter-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a specific Outlook message by ID, which distinguishes it from sibling tools like outlook_search (finding messages) and outlook_draft (creating drafts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a message ID is known, but does not explicitly mention alternatives or when not to use it, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of disclosing behavioral traits. It does state the core mutating action (remove a category) and clarifies that matching is by name. However, it does not disclose potential side effects, failure modes (e.g., if a message does not have the category), or any authorization requirements. This is a reasonable but not comprehensive disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. It contains no redundant words and efficiently conveys the essential purpose and key nuance (name-based removal). This is an example of excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the schema covers all parameters. However, with no output schema and no annotations, the description does not explain what happens after removal (e.g., success/failure feedback) or any side effects. For a mutation tool, this leaves the agent without complete context, though the operation itself is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the baseline is 3. The description adds minimal meaning beyond the schema by emphasizing 'by category NAME' and implying message_ids is an array ('one or more messages'), but these details are already present or easily inferred from the schema. No new parameter semantics are introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove), the resource (category from Outlook messages), and the scope (one or more messages). It also distinguishes by specifying 'by category NAME', which separates it from category operations by ID. This aligns with the sibling tools like outlook_apply_category and outlook_create_category, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to remove a category from messages, use this tool. However, it provides no explicit guidance on when not to use it or mentions alternative tools for related operations. The sibling tools such as outlook_apply_category exist but are not referenced, so an agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the useful detail that times are returned in UTC, but does not state whether the operation is read-only, how results are ordered, or any pagination limits. The description adds some value but lacks richer context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates both the primary action and a key output detail (UTC times). There is no redundancy or filler, so every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could benefit from stating the return structure. However, 'Search calendar events' implies a list of events, and the UTC note adds useful output context. With schema covering all parameters and a simple read-only operation, the description is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters with descriptions. The description mentions keyword matching against titles and UTC times, which aligns with the query and time parameters but does not add syntax or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Search calendar events') and specifies the search scope ('by keyword in the title'). This clearly distinguishes it from sibling tools like calendar_get or calendar_list, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for keyword-based search but does not explicitly mention when to use it instead of alternatives like calendar_list or outlook_search. There is no guidance on when not to use it, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It adds the requirement of at least one criterion and one action, and notes that actions apply automatically, but it does not disclose side effects like immediate activation, rule precedence, or modification/deletion limitations. The forward_to warning lives in the schema, not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero wasted words. It front-loads the main action, adds a clarifying analogy, and states a key constraint. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter creation tool with no output schema, the description covers the core idea, the requirement of criteria+action, and the automatic behavior. It misses some context like whether rules apply to existing messages or only new ones, but overall it's sufficiently complete for an agent to understand the tool's purpose and main constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with meaningful property descriptions, so the baseline is 3. The description introduces the concept of criteria vs. actions, which adds high-level meaning, but it does not map specific parameters to those roles beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create an Outlook inbox rule'. It further clarifies by calling it 'the Gmail-filter equivalent' and describes its function of matching messages by criteria and applying actions, which clearly distinguishes it from sibling tools like outlook_read or outlook_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'Gmail-filter equivalent' and the criteria/action behavior, but it does not explicitly state when to prefer this tool over alternatives or list excluded scenarios. It gives context but lacks direct when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does add a valuable caution about automatic notifications to attendees, but it omits other important traits such as partial-update behavior, permission requirements, and behavior when the event does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: one for purpose and one for a crucial side effect. Every word contributes, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the purpose and the attendee-notification side effect are covered, the absence of an output schema and annotations leaves gaps around return values, partial-update semantics, and failure conditions. This makes the description only moderately complete for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters effectively. The description adds no extra parameter-specific meaning beyond what the schema provides, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Modify') and the resource ('an existing calendar event'), making it obvious what the tool does. This distinguishes it from sibling tools like calendar_create and calendar_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Modify an existing calendar event' clearly implies the use case, but it does not explicitly mention when to prefer this tool over alternatives or when not to use it. The context is clear enough for the common scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds one useful behavioral trait: availability is derived from events not marked 'free', meaning free events are not counted as busy. However, it does not describe return format, timezone handling, or edge cases like overlapping events, which would provide fuller transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and core logic. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description is nearly complete: it covers purpose, date range capability, and the underlying rule for free/busy. Minor gaps include absence of return value details and explicit handling of annotations, but the tool's simplicity keeps this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (account, date_end, date_start) already described in the schema. The description mentions date range, which aligns with date_start/date_end, but adds no extra meaning beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('free/busy status') with scope ('for a date or date range'), clearly distinguishing it from sibling tools like calendar_search and calendar_get. It also adds a key nuance about how availability is derived ('from events not marked free').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need free/busy information rather than event details. It provides clear context (checking availability) but does not explicitly exclude alternatives or name a preferred sibling for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple creation statement by revealing a non-obvious default: attendees are NOT invited by default, and their names are placed in the description instead. It also explains that setting send_invites=true triggers Outlook to send invitation emails, which is a meaningful side effect. This is strong behavioral transparency, though it could additionally note whether the event is immediately visible or if any authentication is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose ('Create a calendar event'), and immediately follows with a high-value clarification about attendees. There is no redundant information or filler, making it compact and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the primary purpose and the most complex behavioral nuance (invites) for a create tool with 8 parameters and no output schema. However, it does not mention return values, error handling, or account selection, which could be relevant in context. Given the schema covers required fields and property meanings, this is a reasonably complete description, though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the interplay between attendees and send_invites, including the default behavior and the exact effect of setting send_invites=true. This clarifies parameter usage beyond the static schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a calendar event,' a specific verb and resource that clearly distinguishes this tool from siblings like calendar_update, calendar_get, and calendar_delete. The additional detail about attendee invitation behavior further clarifies the tool's exact function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives (e.g., calendar_update for modifications, calendar_availability for checking slots). The usage context is implied by the verb 'create' and the sibling list, but no exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It reveals the surprising behavior (only a title prefix, not a real delete) and explicitly notes the non-destructive nature, which is critical for safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero filler. The key term 'Soft-delete' is front-loaded, immediately conveying the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description adequately covers the core behavior and the important non-delete guarantee. It lacks return value or error details, but those are not essential for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds no extra parameter-level detail; it only provides the overall operation context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('prepend 'DELETE - ' to event title') and the resource (calendar event). It also explicitly distinguishes itself from actual deletion, which separates it from any potential delete-like sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by explaining it's a soft-delete that preserves the event, which helps an agent choose it over a hard-delete alternative. However, it does not explicitly name alternative tools or state when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses the non-sending behavior, the Drafts folder placement, and the server-side permission restriction. This is strong transparency for a creation tool, though it could mention return behavior or failure modes, but those are less critical here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The main action is front-loaded, and the critical caveat about not sending is placed immediately after. The parenthetical explains the reason concisely. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters but the schema fully covers them. The description addresses the most important contextual concern (draft vs send) and the outcome (appears in Drafts). It does not enumerate all parameters, but that is unnecessary given the schema. The description is complete enough for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-specific meaning, but the schema already thoroughly defines each parameter, including the HTML preference guidance. Thus the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the specific verb+resource 'Create a draft email' and immediately clarifies the key distinction: it does NOT send, but creates a draft for manual review. This distinguishes it from any hypothetical send tool and from sibling read/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use: when you want to compose an email without sending it, leaving the draft for manual review. It also states the permission limitation (cannot send), which indirectly says 'don't expect this to send'. It lacks explicit alternatives, but given the sibling set, no other tool creates drafts or emails, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects. It does an excellent job by warning that 'moved messages get NEW message IDs'—a critical, non-obvious behavior—and clarifies it is not a permanent delete. Missing are details like reversibility or permission requirements, but the most impactful behavioral trait is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using two short sentences plus a note to convey the core action, a negative clarification, and a critical warning. Every sentence earns its place, and the key point is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description covers the essential aspects: what it does, what it doesn't do, and a crucial side-effect. It lacks error-handling or response-format details, but given the simplicity, these are not necessary for a basic understanding. Overall, it is complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are well-documented in the input schema (100% coverage): 'account' notes the default, and 'message_ids' describes the array of IDs to move. The description adds no additional parameter-level context beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Soft-delete: move messages to a 'To Be Deleted' folder.' It uses a specific verb (move) and resource (messages to a folder), and distinguishes itself by explicitly saying it does NOT delete or trash messages. This differentiates it from deletion-related tools and is unmistakable in intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for soft-deleting messages by moving them to a specific folder, and the clarification 'Does NOT delete or trash messages' provides a boundary for when not to use it for permanent deletion. However, it does not explicitly name alternative tools for permanent deletion or other actions, leaving the when-not-to-use guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: it returns immediately without blocking, opens a browser tab as a convenience, notes the URL in the response is authoritative (especially for wrong-profile scenarios), and explains background token saving. This goes well beyond a basic 'authenticates' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, and every sentence delivers unique value: the immediate-return behavior, the confirmation tool, and the browser-tab caveat. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an auth tool with no output schema, the description covers the return behavior (consent URL), the user interaction, the background token save, and the follow-up confirmation. It gives the agent and user enough detail to use the tool correctly without any structured outputs to rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter account_name is fully documented in the schema with a default and example ('consulting', 'personal'). The description doesn't add extra semantics, but the schema already provides sufficient meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Authenticate a Microsoft account' – a specific verb and resource – and clarifies the account types (M365 work/school or personal/Hotmail). It clearly distinguishes itself from sibling tools like microsoft_status (which confirms auth state) and the calendar/outlook tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to give the consent URL to the user, explains the flow (user approves in browser, token saves in background), and directs confirmation via microsoft_status. It doesn't mention when-not-to-use or alternative tools, but the multi-step usage guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses a key behavioral trait: the tool performs a LIVE credential check against Microsoft, which implies network access and up-to-date validation, as opposed to reading local file state. It also explains the meaning of the 'needs_reauth' tokenStatus, offering useful output interpretation. However, it does not mention potential side effects, permissions, or latency, though for a status check these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no wasted words. The first sentence states the tool's core function and a key nuance (LIVE vs local). The second sentence provides an actionable conditional that enriches the output understanding. Every element earns its place, and it's front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is remarkably complete. It explains what the tool does, what the key output value means, and what action to take if that value appears. This gives the agent a full procedural loop. The 'not just local file state' clarification adds important context about the check's real-time nature, covering the tool's operational context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description needs to explain no input semantics. Per the rubric, 0 params yields a baseline of 4. The description adds no parameter information because none exists; the schema is empty, and the tool is entirely stateless from an input perspective.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Check connection health for all configured Microsoft accounts'. It also distinguishes itself by emphasizing a 'LIVE credential check against Microsoft (not just local file state)', which differentiates it from sibling tools that might check local state. The mention of the tokenStatus output and its meaning further clarifies the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear directive for when re-authorization is needed: 'tokenStatus 'needs_reauth' means run microsoft_auth for that account', explicitly naming the alternative tool and the condition to use it. It implies this tool is used to assess connection health, but does not explicitly state when not to use it or list other exclusions, leaving a slight gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/marianasmall/mariana-outlook-mcp'

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