outlook-personal-mcp
Server Quality Checklist
Latest release: v0.1.1
- Disambiguation5/5
Each tool targets a distinct resource and action: folder operations are separate from message operations, and draft/attachment/calendar tools are clearly partitioned. Even overlapping tools like list_messages vs search_messages are differentiated by filtering vs full-text search. No two tools appear to do the same thing.
Naming Consistency5/5The vast majority follow a consistent verb_noun pattern (delete_folder, send_mail, create_event). Minor deviations like whoami and short verbs reply/forward are still intuitive and do not disrupt the overall predictable scheme.
Tool Count4/5At 31 tools, this is a relatively large surface, but the server covers two major domains (mail and calendar) with comprehensive operations. Each tool maps to a meaningful operation, so while the count is above the typical 3-15 range, it is justified by the scope and does not feel padded.
Completeness5/5The tool set provides full lifecycle coverage for folders, messages, drafts, and calendar events: create, read, update, delete, search, and specialized actions (reply, forward, respond, find_availability). There are no obvious dead ends; every workflow from composing a draft to sending it, or from listing events to updating them, is supported.
Average 3.5/5 across 31 of 31 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under 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.jsonto 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 annotations present, the description adds no behavioral context beyond what readOnlyHint=false already implies. It does not disclose potential side effects such as renaming affecting child folder paths, failure modes when the folder does not exist, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. It is concise with no wasted words, though its brevity borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no output schema and no enums, but the description fails to mention important constraints like non-renamable system folders, character limits, or hierarchical implications. It is minimally complete for a trivial rename but lacks the context needed for safe invocation in a mail system with folder hierarchies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it does not explain folder_id or new_name at all. The parameter names are self-explanatory, but no additional meaning (e.g., format constraints, required permissions, or examples) is provided, leaving the semantics entirely to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'rename' and the resource 'mail folder', making the action clear. It is distinct from sibling tools like create_folder and delete_folder, though it lacks any additional scoping or clarifying details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool, nor does it mention any prerequisites or alternatives. There is no context about folder existence, system folder restrictions, or relationship to create_folder/delete_folder.
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?
Annotations already declare readOnlyHint=false and destructiveHint=false, and the description merely restates the copy operation without adding context such as whether the original remains, permission requirements, or return values. It adds no behavioral information beyond the title and name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. However, it may be too terse, omitting important context, but as a statement it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description is minimally sufficient but lacks key context such as behavioral difference from move_message, whether the copy preserves metadata/attachments, or what the response contains. Given the sibling tools include move_message, this missing distinction is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the two required parameters beyond their self-explanatory names (message_id, destination_folder_id). It fails to compensate for the missing schema descriptions, leaving the agent to rely on parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'copy' and specifies the resource (message) and target (another folder), making the primary action clear. It distinguishes from 'move_message' implicitly via the term 'copy', but does not explicitly state that the original is retained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool instead of siblings like move_message. The description lacks any exclusions or alternative recommendations, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, giving a basic safety profile. The description adds the key behavioral fact that the message is not sent, which is beyond annotations. However, it does not disclose other behaviors such as persistence, return value, or whether drafts are immediately visible, so the addition is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which is structurally concise. However, it is severely under-specified, failing to provide adequate information for correct tool usage. This is under-specification rather than commendable conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and zero parameter documentation in the description, the tool is inadequately specified. The description does not explain expected inputs, output, or side effects beyond the basic 'create a draft' notion, leaving the agent to guess at details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It provides no clarification for parameters like 'html' (whether body is HTML) or 'cc' (array of addresses), leaving the agent to rely solely on schema types without semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a draft message (not sent)' has a specific verb and resource, and explicitly clarifies that the message is not sent. This distinguishes it from send_mail and send_draft, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 send_draft or update_draft. The parenthetical '(not sent)' implies use for preparing messages, but no explicit circumstances, prerequisites, or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, but the description itself does not disclose key behavioral traits such as whether the reply is sent immediately or creates a draft, or what side effects occur. The minimal text adds little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no unnecessary filler. The parenthetical is slightly awkward but overall the text is concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, three schema parameters, and zero param descriptions, the description is too thin to be complete. It does not explain return values, the effect of the reply, or the role of message_id, leaving the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the reply_all parameter, leaving message_id and comment without any clarifying context. This is insufficient for a tool with three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Reply to a message' with a specific verb and resource. It also adds a brief note about the reply_all parameter, but it does not explicitly distinguish this tool from siblings like forward or send_mail, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as forward or send_mail. The parenthetical about reply_all is more of a parameter behavior note than usage guidance. There is no mention of prerequisites or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only operation. The description adds a helpful note about save_to_sent to skip saving to Sent Items, which is beyond annotations, but it contains a typo and does not disclose other behavioral aspects like error outcomes or delivery semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded with the core purpose. However, the typo reduces quality slightly, but it is still concise and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters, no output schema, and the complexity of email sending, this description is far too thin. It doesn't mention success/failure feedback, attachments, or relationship to drafts, leaving significant gaps that the agent must handle blindly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description was expected to explain parameters, but it only references save_to_sent (incorrectly as 'save_to_ssent') and omits all other required/optional parameters like to, subject, body, cc, bcc, and html. The agent is left to infer from schema names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Send an email,' which is a specific verb+resource combination. It is distinguishable from siblings like reply, forward, and send_draft, though not explicitly differentiated, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use send_mail versus alternatives like send_draft or reply. There is no mention of exclusions or suitable contexts, 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds no additional behavioral context, such as whether the message is removed from its original folder (implied by 'move' but not explicit) or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is clear and free of filler. It is appropriately sized for a simple operation, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description plus annotations provide a basic understanding. However, there is no mention of return values, error conditions, or the effect on the source folder, which are gaps for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain message_id or destination_folder_id beyond their titles. With no parameter details in the description, the agent cannot infer semantic meaning such as expected format or relationship between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('move'), the resource ('message'), and the destination ('another folder'). It distinguishes from sibling tools like copy_message by implying relocation rather than duplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 copy_message or delete_message. The description simply states what it does without context on appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that it uses Graph getSchedule and covers 'given people for a time window,' providing some scope context. However, it does not disclose behaviors like pagination, rate limits, or how timezone and interval settings affect results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. It immediately conveys the core function and the underlying API in parentheses. This is an example of efficient, front-loaded writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists and annotations cover safety, so the description doesn't need to explain returns or risk. However, it omits usage guidance and parameter details for time_zone and interval_minutes, which are important for correct invocation. Given the tool's relative simplicity, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'given people' which maps to emails, and 'time window' which maps to start and end, but provides no explanation for time_zone or interval_minutes, which have defaults but unclear semantics. The description thus only partially covers parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides free/busy information for specified people within a time window, referencing Graph getSchedule. This clearly identifies the resource and scope, distinguishing it from event management siblings like list_events or create_event. However, it uses a noun phrase rather than an explicit verb, making it slightly less direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as list_events or search_events. The description only states what it does, not when it should be preferred. There is no mention of scenarios like pre-meeting scheduling checks or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false, so the safety profile is clear. The description adds a useful behavioral detail about using calendarView when start and end are provided, but doesn't disclose default behavior without those parameters or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action. No redundant details or filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained. However, the description lacks information about which calendar is being listed, default time window when start/end are absent, and pagination behavior, making it slightly incomplete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It explains the ISO 8601 format for start and end and their role in defining the window, but completely omits the 'top' parameter, leaving its purpose unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List events' as the action, which identifies the primary function. However, it does not explicitly distinguish from sibling tools like search_events or get_event, though the title and context imply calendar events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of when to prefer list_events over search_events, get_event, or list_calendars.
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?
Annotations already indicate this is not read-only and not destructive, but the description adds no extra behavioral context such as side effects (e.g., draft being sent/moved), permissions required, or rate limits. With annotations present, the bar is lower, yet the description provides zero additional 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/5Is 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 purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, the description is too sparse. It omits return value information, side effects, and any distinguishing context from send_mail or reply, leaving the agent under-informed for a consequential action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies draft_id refers to an existing draft but does not explicitly explain the parameter, its importance, or how to obtain the ID. The word 'existing' provides minimal semantic link.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send an existing draft' clearly identifies the action (send), the resource (draft), and the scope ('existing'), distinguishing it from siblings like create_draft, send_mail, or reply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of send_mail or reply, nor any prerequisites or exclusions. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds only a vague 'and/or' hint about partial updates, but it does not disclose behavior for null vs omitted fields, the html flag's effect, or what happens if the draft_id does not exist. With annotations present, the description adds minimal extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant phrases. It is front-loaded with the action and resource, making it appropriately sized for a simple update tool. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity (4 parameters, 1 required, no output schema), the description provides very little surrounding context. It does not mention return value, error conditions, or the role of html. For an agent deciding when to invoke this tool and what to pass, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters. It names subject and body but omits html entirely and does not clarify the meaning of null defaults or how html interacts with body. draft_id is implicitly clear, but overall the description fails to cover all parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a draft's subject and/or body.' clearly identifies the action (update), resource (draft), and specific fields (subject/body). It distinguishes from sibling tools like create_draft and send_draft, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, such as create_draft for new drafts or send_draft for sending. There are no stated prerequisites, exclusions, or context. The usage is only implied by the tool name and generic phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose non-read-only, idempotent, and non-destructive behavior. The description adds the reversibility insight (flag/unflag), but offers no additional context about what flagging affects or any side effects. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and clear, but it is slightly under-specified for a tool with two parameters, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and two parameters, the description is incomplete. It omits parameter usage guidance, when to choose this tool over siblings, and the impact or meaning of the flag status in the email context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly map the 'flagged' parameter to true/false or explain the 'message_id' requirement. While the boolean parameter is inferred, the description does not compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verbs 'flag' and 'unflag' with the resource 'message', clearly conveying the action and its dual nature. This distinguishes it from sibling message operations like mark_read or delete_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or relationships to sibling tools such as mark_read or move_message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it is a 'Full-text search' (searching entire message content) and mentions 'Graph $search', which signals specific API behavior. However, it does not disclose pagination behavior, query syntax, or result ordering, so transparency is limited but present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence conveys the core purpose without unnecessary words. It is concise and front-loaded, though it lacks structure like usage examples. It is appropriately sized for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and simple parameters, the description omits essential context for effective use: no query syntax guidance, no note on result limits, and no relation to sibling tools. The tool is part of a rich email/calendar set, and this description leaves an agent with too little to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for undocumented parameters. It does not explain what 'query' should contain (e.g., KQL syntax) or what 'top' limits (e.g., number of results). The phrase 'Full-text search' implies query is the search string, but no syntax or defaults are clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and the resource ('the mailbox'), specifying 'Full-text search' to indicate scope. It distinguishes from siblings like 'search_events' (which searches calendar events) and 'list_messages' (which lists without full-text search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention exclusions or reference sibling tools, so an agent cannot tell from the description alone whether to use search_messages or list_messages / search_events for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds the 'free text' search behavior, which is useful beyond annotations, but it does not disclose other behavioral traits such as result limits (top parameter) or which event fields are searched. Since annotations cover safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action and resource. Every word adds value, with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the description is too sparse for effective tool selection and invocation. It lacks details about search scope, parameter semantics, and when to use this tool vs siblings, making it incomplete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for both parameters. The description only implicitly covers 'query' via 'free text', but the 'top' parameter (result limit) is completely unexplained. With low schema coverage, the description should compensate, but it does not adequately describe either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Search') on a specific resource ('events') using a clear method ('by free text'). This distinguishes it from sibling tools like list_events (which lists all events) and search_messages (which searches messages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 list_events or get_event. The phrase 'by free text' implies usage for text-based event lookup, but 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. The term 'cancel' hints at calendar-specific semantics (such as notifying attendees) compared to plain 'delete', but it does not elaborate on side effects, permanence, or idempotency. The annotations already declare destructiveHint=true, so the description is not required to repeat safety, but it falls short of providing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant wording. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive action with annotations covering the safety profile, the description is minimally adequate. However, it lacks information about the distinction between delete and cancel, potential consequences (e.g., notifications to attendees), and reversibility, which would be valuable for a destructive calendar operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The event_id parameter is not described at all in the description, and schema_description_coverage is 0%. The parameter name is self-explanatory, but the description fails to clarify format, requiredness, or semantics beyond the name, leaving the agent without supportive context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('delete/cancel') on a specific resource ('calendar event'), distinguishing it from sibling delete tools for folders or messages. The verb is unambiguous and the resource is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 update_event or respond_event. It does not mention scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, and the description consistent with these does not contradict them. It adds the context that the file is local, which is a useful distinction, but does not disclose other behavioral traits like potential file uploads or side effects on the draft.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose without any filler. Every word earns its place, making it highly concise and appropriately structured for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (two self-explanatory parameters, annotations provided, no output schema), the description is largely sufficient for basic invocation. It clearly identifies the action and target, though it could benefit from noting that the draft must already exist or that this modifies an existing draft.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters. It only marginally clarifies that file_path refers to a local file, but provides no details on format, constraints, or how draft_id and file_path are used beyond what their names imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach a local file to a draft' states a clear verb (Attach) and resource (local file to a draft), distinguishing it from sibling tools like list_attachments and download_attachment. The action is unambiguous and aligns with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 create_draft or update_draft, and does not mention prerequisites (e.g., the draft must exist) or edge cases. It simply states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false). The description adds useful context that times must be ISO 8601 in the specified time_zone, which is non-obvious. However, it does not disclose side effects like attendee invitations or calendar selection behavior, but the annotations provide a basic safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the core purpose and the most critical input format requirement. Every clause adds value, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no parameter descriptions, the description is too minimal to provide a complete picture. It omits return value expectations and meanings of non-obvious parameters like attendees and is_online_meeting. The addition of time zone handling is helpful but leaves major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies the time_zone parameter and ISO 8601 format for start/end. The remaining parameters (subject, body, location, attendees, is_online_meeting) are left entirely to their names, which can be ambiguous (e.g., attendees format). This does not sufficiently compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'create' with the resource 'calendar event', clearly distinguishing it from sibling tools like update_event or delete_event. The added time format clause reinforces the function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new calendar events but provides no explicit guidance on when to prefer it over alternatives or exclusions, such as using update_event for modifications. No alternative tools are referenced, so the agent must infer from the verb 'create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and openWorldHint=true, so the agent knows it is a mutation with potential external side effects. The description adds the allowed response values but does not disclose other important behaviors, such as how send_response affects whether the response is delivered. No contradiction with annotations, but limited added 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences containing only essential information. The action verb and resource are front-loaded, and the list of valid response values is directly useful. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and zero schema descriptions, the description feels incomplete. It doesn't cover the meaning of 'send_response' or 'comment', nor what constitutes a successful response. For a mutation tool with external side effects, this is insufficient for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'response' parameter with enum values, but completely ignores 'comment' and 'send_response', which are not self-explanatory. 'send_response' in particular controls whether the response is actually sent, and leaving it undocumented is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Respond to a meeting invite' and specifies the valid response values (accept, decline, tentative). This distinguishes it from sibling tools like update_event or create_event, as it is uniquely about responding to an invitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to RSVP to a meeting invite) but does not explicitly contrast it with alternatives like update_event or mention when not to use it. It provides basic context but lacks clear exclusions or alternative 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?
Annotations already declare readOnlyHint=false and destructiveHint=false, and the description's 'Create' aligns with those. The description adds the nuance of optional nesting under parent_folder_id, which is useful behavioral context. However, it does not disclose other aspects like permission requirements, uniqueness constraints, or return side effects beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the purpose and the key option. It is appropriately sized for a simple tool, with zero redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is straightforward (2 params, no output schema), but the description omits any mention of return value or error conditions. For a create operation, users would benefit from knowing whether it returns the created folder object or just an ID. The annotations cover the safety profile, but the description remains too sparse to be complete for even a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It gives meaning to parent_folder_id by explaining it enables nesting, but it does not explain 'name' beyond the schema's title. Since 'name' is self-explanatory as a string, the description provides at least partial parameter semantics, but not complete compensation for the lack of coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create a mail folder') and its scope ('optionally nested under parent_folder_id'). This specific verb+resource pattern distinguishes it from sibling tools like delete_folder and rename_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by context—this is the tool for creating folders—but it does not explicitly state when to use it versus alternatives or exclude other cases. For example, it doesn't mention when to prefer rename_folder or delete_folder. The nesting detail hints at one use case but provides no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, and the description does not contradict them. However, it adds no extra behavioral context such as overwrite behavior, permission requirements, or that the operation is local to the server. Since annotations carry the safety profile, this is baseline for an annotated 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. Every word contributes to conveying the tool's action and destination.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple download tool but lacks important contextual guidance: no usage context, no parameter details beyond names, and no indication of return values (no output schema). With 0% schema coverage and missing usage guidelines, it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies 'save_path' by saying 'local file path', but message_id and attachment_id are left only to their self-explanatory names. No additional semantics are provided for these parameters, though the names are meaningful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('download') and resource ('attachment') with a clear destination ('local file path'), making its purpose unambiguous. It distinguishes itself from sibling tools like list_attachments and get_message by indicating an action that retrieves content to a file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an attachment's content is needed locally, but it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like obtaining message_id and attachment_id from list_attachments. Context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds that the response includes body and attendees, which is useful but not extensive. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the action, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple get-by-id nature, the description is adequate: it states what is returned (body, attendees) and annotations cover safety. It doesn't mention edge cases like non-existent events, but that is optional for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, event_id, with no description (0% coverage). The description does not explain the parameter beyond implying 'one event', so it fails to compensate for the schema's silence. The self-explanatory name helps, but the description adds no explicit semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'event' and scope 'one event', clearly distinguishing it from list_events and search_events. It also mentions the key contents (body, attendees), making its function 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single event by ID ('one event'), but it does not explicitly state when to prefer this over list_events, search_events, or other calendar tools. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral context by specifying the ordering as 'newest first' and the ability to filter by folder or unread status, which goes beyond the annotations. However, it does not disclose pagination behavior via top/skip or the default scope when no folder is specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, front-loaded with the verb and resource. It is concise and every phrase adds value: 'newest first', 'folder', 'unread only' are all meaningful details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters and an output schema, the description covers the essence of listing messages and the filters, but omits pagination semantics (top/skip). The output schema handles return values, so the primary gap is the lack of guidance on how to page through results or the default page size, leaving the agent partially under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly mentions folder and unread filters ('Optionally restrict to a folder or unread only'), but it does not explain the top and skip parameters, which are crucial for pagination. The agent must infer their meaning from property names/defaults, making the description insufficient for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'messages', with specific ordering ('newest first') and optional filters ('folder or unread only'). This distinguishes it from sibling tools like search_messages (search) and get_message (single message retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing messages, optionally restricted by folder or unread status, but it does not explicitly contrast with alternative tools. Sibling tools such as search_messages or get_message could serve related purposes, yet no exclusions or guidance on when to choose this tool over them is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds the boolean semantics (True/False) but no additional behavioral context such as effects on other tools or permissions. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately explains the tool's action and the boolean's meaning. Every word is necessary, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 strong annotations (idempotent, non-destructive), the description is sufficient. It could mention idempotence or prerequisites, but the annotation and simple schema make the tool easy to understand. No output schema means no need to describe returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It explains the 'read' parameter ('read=True or read=False') but adds nothing about message_id beyond what the schema already states (type string, required). This is partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Mark'), a clear resource ('a message'), and the exact state change ('read=True' or 'read=False'). This clearly distinguishes it from sibling tools like flag_message, move_message, or delete_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—setting read/unread status—but does not explicitly state when to use this tool versus alternatives or any exclusions. No guidance on when not to use it is provided, so it meets only the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a non-read-only, non-destructive, idempotent operation. The description adds key behavioral context by stating 'only provided fields change', which clarifies partial-update semantics and that omitted fields are left untouched. This goes beyond the annotation information, though it does not address edge cases like null values or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and scope without any redundancy or filler. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary update behavior but omits the return value or response format, which is important since there is no output schema. It also does not mention error scenarios or prerequisites like the event existing. While the annotations and schema cover some context, the lack of return-value disclosure leaves a gap for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the meaning of the six parameters. It only provides a general rule for 'provided fields' but does not explain formats (e.g., date/time for start/end), the semantics of null, or the role of time_zone. Parameter titles are self-explanatory but insufficient for precise invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Update fields') and resource ('existing event'), with the parenthetical 'only provided fields change' adding precise scope. This distinguishes it from sibling tools like create_event and delete_event, which have different verbs and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing event' implies this is for modifying already-created events, not for creating new ones (which would use create_event). However, it does not explicitly mention alternatives or conditions when not to use it, leaving usage largely implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as destructive (destructiveHint=true) and not read-only. The description adds a crucial behavioral detail: deletion is not permanent but moves the folder to Deleted Items. This goes beyond the annotation's binary safety flag, providing recovery 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded with the action and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one parameter and no output schema. The description covers the core function and the key nuance of moving to Deleted Items. While it omits details about consequences for contained messages or folder hierarchies, the core usage is clear and the description complements the annotations well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one required parameter, folder_id, and the description does not elaborate on its meaning or format beyond the schema's type/title. With 0% schema description coverage, the description fails to compensate by explaining what folder_id identifies or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as 'mail folder', and further clarifies the behavior by noting it moves to Deleted Items. This clearly distinguishes it from sibling tools like create_folder and rename_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, such as using move_message for individual emails or permanent deletion. The context is clear from the purpose, but no exclusions or alternative conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the 'optional comment' detail, but does not disclose other behavioral traits such as whether attachments are included, how the original sender is presented, or side effects beyond the write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and key nouns. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description covers the core action but omits usage context (e.g., differences from reply), return values, or prerequisite conditions. It is adequate for a simple forwarding operation but lacks completeness for an agent to fully anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. 'Forward a message to recipients' maps to message_id and 'to', while 'optional comment' maps to comment. This adds meaning beyond the bare schema, though it does not elaborate on array format or parameter constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Forward a message'), the resource ('a message'), and the recipients ('to recipients'), with an optional comment. This distinguishes it from sibling tools like send_mail and reply, as forwarding implies sending an existing message to new recipients.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one wants to forward an existing message rather than creating a new one, but it does not explicitly state when to use this tool versus alternatives like reply or send_mail. No exclusions or alternative pointers are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior, but the description adds key context: the message is moved to Deleted Items and the operation is reversible. This goes beyond the annotation's binary signal and helps the agent understand the actual consequence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words. It is front-loaded and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation, the description covers the action, the target, and the effect. It omits non-essential details like permission requirements or failure modes, which are not critical given low tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for message_id (0% coverage). The description does not explicitly elaborate on the parameter, but the name is self-explanatory and the description implies its role. Minimal added value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete') on a specific resource ('a message') and clarifies the behavior ('moves it to Deleted Items; reversible'). This distinguishes it from sibling tools like delete_folder and move_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear that this tool is for deleting messages, but it does not explicitly state when to prefer it over alternatives such as move_message or permanent deletion. Sibling tools exist but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the specific return fields, clarifying it returns metadata rather than file content, but it does not disclose other behaviors such as error handling or requirements like message existence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema and read-only annotations, the description is sufficient for correct invocation. It clearly states the needed input (a message's ID) and the output (attachment metadata).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. The phrase 'a message's attachments' makes it clear that message_id identifies the target message, adding meaning beyond the bare parameter name, though it does not specify the parameter's format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'a message's attachments' and enumerates the returned fields (id, name, size, contentType), making its function clear and distinct from sibling tools like download_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to list attachment metadata but provides no explicit guidance on when to choose it over related tools like download_attachment or get_message. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the user scope ('the user's calendars'), which provides some behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly one sentence, with no waste. It is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, read-only, output schema available), the description is sufficient. It clearly scopes the result to the user's calendars without needing to explain return values, which the output schema would cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so the description does not need to explain parameter semantics. The baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('the user's calendars'). It distinguishes from sibling tools like list_events and list_folders by naming a different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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, but the resource name 'calendars' implies its usage. No exclusions or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail that include_body controls whether the full body text/HTML is returned, which helps the agent understand response variability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the core action and adding only the key parameter clarification. Every word contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers the essential purpose and parameter behavior. It does not describe return format or error scenarios, but these are less critical given the read-only annotation and clear sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining include_body's effect. The message_id parameter is self-explanatory from the context and schema, but the description could have elaborated on return format more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'a single message,' using a specific verb and singular resource. This distinguishes it from sibling tools like list_messages and search_messages, which operate on multiple messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Get a single message' implies when to use this tool, but there is no explicit guidance about alternatives or when not to use it. Sibling tool names provide context but the description itself does not direct the agent.
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 annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds the specific behavior of returning unread/total counts. This is useful context beyond the annotations, though it does not describe pagination or folder filtering behavior. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that is front-loaded with the action and resource, and every word earns its place. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters), the existence of an output schema, and strong annotations, the description is fully sufficient. It notes the key output detail (unread/total counts) and does not need to describe return structure since the output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter-specific semantics (there are none), but it does clarify the output includes counts, which is beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('mail folders') and adds a distinctive detail ('with unread/total counts') that clearly separates it from sibling tools like list_messages or folder mutation tools. It immediately conveys 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving folders and their counts, but it does not explicitly state when to prefer this over list_messages or provide any exclusion guidance. The intended context is clear from the name and description, but no explicit alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'Microsoft account' specificity but does not disclose additional behavioral details (e.g., failure modes, auth requirements). This meets the minimum bar without extra richness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that says everything needed with no redundancy or filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's trivial complexity (zero parameters, no output schema, read-only annotation), the description is fully adequate. It clearly states what the tool returns and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the parameter burden is minimal. The description correctly implies there is nothing to configure, and the schema confirms this. A baseline of 4 applies per the rubric for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('the signed-in user's Microsoft account profile'), clearly conveying the tool's purpose. It is unique among siblings, as no other tool provides this functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit alternatives or exclusions are mentioned, the tool's purpose is self-evident and there is no overlapping sibling tool. The context is clear: use this to get the current user's profile, and no other tool serves that role.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/salahawad/outlook-personal-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server