iCloud MCP Server Apple
Server Quality Checklist
Latest release: v2.1.1
- Disambiguation4/5
Tools are grouped by domain (notes, messages, safari, email, calendar, contacts, reminders), each handling a distinct resource or action. Search vs list tools are differentiated by description (search filters, list enumerates), and meta tools are clearly separate. Minor overlap exists between search-notes/list-notes and search-contacts/list-contacts, but descriptions resolve ambiguity.
Naming Consistency5/5All tools follow a consistent lowercase verb-noun pattern with hyphens (e.g., list-notes, create-event, read-contact). Verbs like search, list, get, create, update, delete, read, send are used uniformly across domains. This creates a predictable and navigable naming scheme.
Tool Count2/541 tools is far beyond the 'heavy' threshold, even for a multi-domain iCloud integration. The large number will increase agent context overhead and selection difficulty, despite being organized per service. A more focused server per domain or consolidation of similar tools would improve coherence.
Completeness4/5Coverage is strong overall with full CRUD for calendar, contacts, and reminders, plus list/read/send for email and messages. However, notes lack update and delete operations, email lacks delete/move, and messages lack any delete/archive capability. These are minor gaps given the primary read/send use cases, but they prevent full workflow completion.
Average 4/5 across 41 of 41 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 47 commits in the last 12 weeks
- Last stable release on
- 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-readOnly side-effecting operation, and the description is consistent with that. However, the description adds no additional behavioral context such as whether the reaction is attached to a specific message, how failures are handled, or potential side effects beyond the reaction itself. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that lists the reaction types and conveys the core action without extraneous content. It is well-structured and easy to parse.
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?
This tool has no output schema and minimal annotations, so the description must carry the full explanation. It fails to explain that reacting to a message requires a target message, how to identify it, or whether the reaction applies to the most recent message. This is a significant gap for correct invocation; the description is too sparse to be complete.
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 covers both parameters with descriptions, but the tool description adds no meaning beyond repeating the enum values already present in the schema. Critically, the schema includes only chatId and type, lacking a message identifier, and the description does not clarify how a target message is selected—rendering parameter semantics incomplete.
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 a specific verb ('Send') and resource ('tapback reaction') and lists the allowed reaction types, making the core purpose clear. However, it does not explicitly distinguish itself from the sibling tool 'send-message', and notably omits any mention of which message the reaction is applied to (no messageId in the schema).
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?
There is no guidance on when to use this tool versus alternatives like 'send-message' or 'read-messages'. No prerequisites (e.g., existence of a message to react to) or exclusions are provided, leaving the agent to infer usage context.
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?
The description simply restates the action without disclosing behavioral traits beyond the annotations. Annotations already indicate readOnlyHint false and non-idempotent, but the description does not add context such as duplicate event creation on repeated calls or calendar-specific behavior. No contradiction with 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, clear sentence with no superfluous words. It is efficiently structured and front-loaded, though it omits additional helpful details.
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 7 parameters, 3 required, and no output schema, the one-sentence description is insufficient. It does not explain what the function returns, how calendars are selected (e.g., calendarUrl vs calendarName), or any side effects. The schema covers parameters but the overall context for using the tool is minimal.
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 input schema has 100% parameter description coverage, so the schema fully documents each parameter. The description adds no additional parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function—creating a new calendar event—using a specific verb and resource. This distinguishes it from sibling tools like update-event, delete-event, and list-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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as calendar selection or authentication. It is implied by the name, but no explicit context 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 declare the tool destructive and non-read-only, and the description adds no additional behavioral context beyond the plain action. It doesn't mention consequences of closing a tab (e.g., unsaved data, irreversibility) or error handling. Since annotations cover the safety profile, the low score reflects that the description contributes nothing beyond 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?
A single, direct sentence with no filler. Perfectly concise for the action it describes.
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 tool has two optional parameters and no output schema; annotations provide safety context. The description is minimal but works in combination with the schema. However, it lacks explicit mention of default behavior (e.g., 'if omitted, closes current tab') which is only in the schema, and no usage guidance is given. This is a minimum viable description.
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 input schema provides complete descriptions for tabIndex and windowIndex (100% coverage), so the description doesn't need to explain them. The baseline is 3 because the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Closes' and resource 'Safari tab', clearly distinguishing the action from sibling tools that list or open tabs. It directly states 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 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, nor any prerequisites or behavioral notes. It simply states the action. The schema mentions optional parameters but the description doesn't explain usage context.
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, indicating this is a write operation. The description adds no further behavioral context, such as whether the note is created in a default folder, any auth requirements, or side effects. It neither contradicts nor enriches the annotation-provided 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 sentence, 'Creates a new note', which is maximally concise and front-loaded. It contains no filler words or redundant clauses, making it an efficiently sized statement of purpose.
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 tool is simple, and the schema fully documents all parameters with descriptions. Annotations convey the write-safety profile. However, the description lacks usage guidance or any mention of behavior beyond the bare action, making it minimally viable but not complete from an agent-facing perspective.
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?
All three parameters (body, title, folderName) have descriptions in the input schema, achieving 100% schema description coverage. The description itself provides no parameter-level details, so it leans entirely on the schema, earning the baseline 3 for high 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 uses a specific verb 'Creates' and identifies the resource 'note', clearly distinguishing it from sibling tools like search-notes, list-notes, and read-note. There is no ambiguity about what action is performed on what entity.
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. It does not mention any context, exclusions, or alternative tools. The single sentence merely states the action without any situational advice.
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 communicate readOnlyHint=false and idempotentHint=true, and the description is consistent with these. The description adds one useful behavioral constraint: 'LOCAL mode only', which is beyond annotations. No other effects, permissions, or edge behaviors are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose and a key constraint in a compact form. There is no wasted text, and it is appropriately sized for a simple update operation.
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 tool is simple with only five parameters and no output schema. The description covers the basic purpose but omits details like behavior when the reminder does not exist or what the return value is. Given the annotations provide safety context, this is minimally adequate but not rich.
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 100%, so the schema fully documents all five parameters. The description adds no additional parameter-level semantics beyond what the schema provides, which meets the baseline but does not exceed it.
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 identifies the action ('Updates') and the resource ('existing reminder'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'update-event' or 'complete-reminder', though the resource name makes it obvious.
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 such as 'create-reminder' or 'complete-reminder'. The only context provided is 'LOCAL mode only', which limits the environment but does not clarify selection criteria.
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 destructiveHint: true and idempotentHint: true, so the destructive nature is known. The description adds a mode constraint 'LOCAL mode only', which is useful extra behavior not in annotations. However, it doesn't explain the implications of deleting in other modes or whether the action is reversible (though destructiveHint implies not). No contradictions with 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 short sentence with no filler words. It front-loads the action and appends the mode constraint. Every word adds value – it is appropriately concise for a simple tool.
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 delete tool with one parameter and annotations covering destructive/idempotent behavior, the description is mostly complete. However, the 'LOCAL mode only' parenthetical is ambiguous (tool availability vs. data scope), and nothing explains what happens if the reminder doesn't exist or how mode interacts with other tools. The absence of an output schema is acceptable, but the mode ambiguity leaves a gap.
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 already covers the sole parameter reminderId with a description 'ID of the reminder to delete (required)'. The tool description adds no additional parameter details, such as how to obtain the ID or format. With 100% schema coverage, the baseline is 3, and the description doesn't exceed 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 a specific verb 'Deletes' and identifies the resource 'a reminder', making the core action unambiguous. The parenthetical 'LOCAL mode only' adds a scope constraint, though it could be clearer whether it refers to the tool's availability or the data type. It distinguishes from sibling tools like complete-reminder by the delete verb.
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 complete-reminder or update-reminder. The only usage hint is 'LOCAL mode only', which is a restriction but not a directive or comparison. No alternatives are named, and no prerequisites (e.g., checking mode via check-auth-status) 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 idempotentHint=true, covering the safety profile. The description adds the scoping to a specific conversation, which is useful. However, it does not disclose return ordering, pagination, or how attachments are handled beyond the schema's parameter hints.
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 redundant information. It achieves maximum clarity with minimal words, fully satisfying the conciseness criterion.
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 5 fully described parameters and annotations declaring a safe read operation, the description provides a minimal but adequate overview. However, it lacks guidance on output format, defaults, or how this tool fits with siblings like list-chats, which is notable since there is no output schema.
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 100%, with each parameter (chatId, start, end, limit, attachments) having a clear description. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate as the schema does the heavy lifting.
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 specifies the verb-resource pair 'Read message history' and narrows the scope to 'a specific iMessage/SMS conversation', which clearly distinguishes it from sibling tools like send-message or list-chats. It could be more explicit about differentiation, but the core 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving messages from a specific conversation, but it does not explicitly state when to use it versus alternatives like list-chats or search-notes. No exclusions or comparison guidance is provided, leaving usage context to inference.
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?
The description adds no behavioral context beyond what the annotations already provide (destructiveHint=true, readOnlyHint=false). It does not mention permanence, side effects, or any consequences of deletion. With annotations already labeling the operation as destructive, the description contributes little additional information.
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 unnecessary words. It stays focused and front-loaded, clearly stating the core action 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 delete tool with one parameter, the description and schema provide sufficient context. The annotation destructiveHint=true already alerts the agent to the destructive nature. The parameter description tells how to source the event handle. While a note about irreversibility would be nice, the existing structured data covers the essentials, making this reasonably 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?
The input schema provides full coverage (100%) with a clear description for the only parameter: 'Event handle from list-events: the URL in cloud mode, the UID in local mode'. The tool description itself adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Deletes a calendar event'. This directly distinguishes it from sibling tools like create-event, update-event, and list-events.
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 gives no explicit when-to-use or alternative guidance. Usage is implied by the tool name and the parameter description that mentions getting the event handle from list-events, but there is no explicit context or exclusion. The need to first call list-events is hinted at in the schema, not in the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. While 'all' hints at complete enumeration, there is no mention of pagination, ordering, or potential side effects. Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description contributes little 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 that directly states the tool's action and scope. Every word earns its place, and there is no verbose or redundant content.
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 that the tool has no parameters, an existing output schema, and a simple enumeration operation, the description is largely complete. However, it could have provided a hint about when to use it relative to sibling tools, and it does not mention whether the result is sorted or complete. Still, for a zero-parameter list tool, this is adequate.
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 schema coverage is 100% with no properties. Per the rubric, a baseline of 4 is appropriate since there is no parameter information needed; the description's mention of 'all email folders' clarifies the scope without needing to document 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 uses the specific verb 'Lists' with the resource 'all email folders', clearly distinguishing it from sibling tools like 'list-note-folders' and 'list-emails'. The inclusion of 'all' and 'email' makes the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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. The description does not mention which sibling tools to use for related operations (e.g., listing emails or notes), nor does it explain the typical workflow context for listing folders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds the specific semantic action (read/unread) but no additional behavioral context such as side effects, permissions, or response 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 a single, clear sentence with no unnecessary words. It is front-loaded and directly states the action.
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 mutating tool with comprehensive schema and annotations, the description is nearly complete. It does not explicitly address mode differences (cloud vs local) hinted by the uid parameter, but the schema covers this. Overall adequate.
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 100%, and each parameter (uid, folder, isRead) is well-documented in the schema. The description adds no extra parameter semantics, so baseline 3 is appropriate.
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 ('marks') and a clear resource ('an email') with a specific state change ('read or unread'). It clearly distinguishes from sibling email tools like send-email, list-emails, or read-email.
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, what prerequisites exist (e.g., having a UID from list-emails), or how it differs from other email actions. The schema hints at mode-dependent UID, but the description itself gives no 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 declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds no extra behavioral context beyond 'Reads', such as behavior on missing notes or output format, but 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, direct sentence with no unnecessary words or repetition. It is appropriately sized for a simple tool and front-loads the core action.
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 one-parameter read operation with annotations covering safety and idempotency, the description is largely sufficient. It could mention return value details or error handling, but these are not critical for this simple tool, and no output schema exists to shift that burden.
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 covers 100% of the parameter semantics with a clear description of noteId. The tool description adds only 'specific note', which is already implied by the schema, so no additional meaning is provided beyond the structured data.
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 reads the content of a specific note, using a specific verb (Reads) and resource (note). It naturally distinguishes from siblings like list-notes and search-notes, which list or search without returning full content for a single note.
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 search-notes or list-notes. There is no mention of prerequisites (e.g., having a note ID already), nor any exclusions, leaving the agent to infer usage solely from the basic action.
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=true and idempotentHint=true, so the description adds no new behavioral context beyond restating that it 'Returns information.' It does not disclose what information is returned, any response format, or potential limitations. The description provides minimal value 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, concise sentence that is front-loaded with the verb 'Returns.' There is no redundant fluff or repetition of the title; every word earns its place.
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's simplicity (no parameters, no output schema), the description is minimally viable but leaves ambiguity about what 'information' means. The agent may not know if it returns server version, capabilities, or status. With sibling tools and a read-only hint, a bit more detail would increase completeness, but it is not severely lacking.
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?
There are zero parameters, and the schema is empty. The baseline for no parameters is 4, and the description does not need to explain parameter semantics. It correctly suggests a call without arguments, though it could optionally hint at return value 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 'Returns' and clearly identifies the resource ('information about this iCloud MCP server'), which distinguishes it from sibling tools that operate on notes, messages, emails, etc. It is unambiguous and tells the agent exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to get server-level information, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or conditions. Sibling tools like check-auth-status or set-mode exist, but no usage guidance or comparison 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 indicate this is a non-read, non-destructive operation. The description adds the important behavioral constraint that it operates only in LOCAL mode, which is not captured by annotations or schema. It does not disclose additional traits like side effects, return values, or failure behavior, so it only partially covers the burden.
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 purpose and a critical constraint with zero wasted words. It is appropriately sized for a simple create operation and achieves maximum conciseness.
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's moderate complexity (5 params, all but one optional), the schema's thorough documentation, and the presence of annotations, the description is adequate but minimal. It states the action and mode restriction but omits any context about behavior, return value, or interplay with other tools. It is sufficient for a straightforward create action but leaves room for more proactive description.
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 input schema provides descriptions for 100% of parameters, so the baseline is 3. The description contributes no additional parameter information, but it does not need to compensate because the schema already fully documents each field. It neither enhances nor detracts from 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 identifies the tool's action ('Creates') and resource ('a new reminder'), with an additional scope constraint ('LOCAL mode only'). It unambiguously distinguishes from sibling create tools like create-event and create-note by naming the specific 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 implies usage through its imperative verb and resource, and the 'LOCAL mode only' qualifier gives a conditional restriction, suggesting it should be used only in local mode. However, it does not explicitly name alternatives or provide when-not-to-use guidance beyond the mode constraint, so it falls short of a clearer guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=true, idempotentHint=true, openWorldHint=true) already convey the read-only, idempotent, and potentially external-state-dependent nature. The description adds the qualifier 'full content', suggesting it returns the complete email rather than a summary, but it does not disclose error handling, folder defaults, or whether attachments are included. This is minimal but not redundant.
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 front-loads the verb and resource. Every word earns its place, with no redundant information 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?
Given the tool's simplicity, strong annotations, and well-described schema, the description is minimally adequate but not fully complete. It lacks detail on the return format (e.g., is it raw text, HTML, or structured JSON?) and behavior for missing or invalid UIDs. Without an output schema, the description should clarify what 'full content' means, leaving some ambiguity for the agent.
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 provides descriptions for both parameters (uid and folder) at 100% coverage. The description's mention of 'by UID' adds no new semantic meaning beyond what the schema already states, so the baseline score of 3 applies. No additional parameter details are provided in the description.
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 'Reads' and resource 'full content of an email' and specifies the key parameter 'by UID', which clearly distinguishes this from sibling tools like list-emails (which lists metadata) and mark-as-read (which modifies state). It is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/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 vs alternatives or provide exclusions. However, the schema description for the uid parameter references list-emails and folder modes, implying a workflow. This is useful context but it resides in the schema, not the description, so usage guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate openWorldHint=true and readOnlyHint=false, which cover the side-effecting nature. The description adds a small detail about new tab/window behavior, but it does not elaborate on permissions, error handling, or effects on existing tabs. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short, front-loaded sentence that conveys the essential action without any waste. It is concise and easy to parse.
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 two-parameter tool with no output schema and good annotation coverage, the description is sufficient. It communicates the core action and the optional new-window behavior. However, it does not specify edge cases like invalid URLs or whether Safari is brought to foreground, which would have made it 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 100% for both parameters (url and inNewWindow), so the schema already documents them. The description does not add any parameter-level semantics beyond what the schema provides, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Opens a URL in Safari' and specifies the resource (Safari) and the action (new tab or new window). It distinguishes from sibling tools like list-safari-tabs, close-safari-tab, and get-current-safari-url by focusing on the opening action.
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 a URL needs to be opened in Safari, but it does not explicitly mention when to use this tool versus alternatives like list-safari-tabs or get-current-safari-url. There are no exclusions or prerequisite conditions 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 declare readOnlyHint and idempotentHint, and the description adds minimal behavioral context beyond restating the check action. It does not disclose what the output looks like or whether a network call is made, but the annotations cover the safety profile adequately.
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 conveys the full purpose without any wasted words. It is front-loaded and easy to scan.
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 tool is simple with no parameters, and no output schema exists. The description says it checks credential configuration but does not specify the return value (e.g., boolean or status object), nor does it provide troubleshooting context. This is a clear gap for such a tool, though the simplicity keeps the score near baseline.
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 schema is trivially complete and the description need not explain any parameter semantics. Baseline 4 applies as the description doesn't need to compensate for missing 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?
The description uses a specific verb ('Check') and a clear resource ('if iCloud credentials are configured correctly'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools, none of which explicitly address authentication or credential validation.
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 credential configuration needs verification, but it does not explicitly state when to use this tool versus alternatives or provide context like 'use before authenticated operations.' No exclusions are given, but the simple purpose allows reasonable inference.
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 idempotentHint=true, so the safe/idempotent nature is covered. The description adds no extra behavioral context such as ordering, pagination behavior, or whether note contents are included. 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, front-loaded sentence with no filler. Every word contributes to understanding the tool's function.
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 two clearly described parameters, an output schema, and thorough annotations, the description covers the essential purpose and usage. No significant gaps are apparent.
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 100%, with clear descriptions for both count and folderName. The description does not add additional meaning beyond the schema, which is the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states the primary action ('Lists notes') and the resource ('notes') with a clear scope ('from a specific folder or all folders'). This distinguishes it from sibling tools like search-notes (searching) and read-note (reading a single note).
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: provide a folderName to list notes from a specific folder, or omit it to list all. However, it does not explicitly state when to prefer this tool over search-notes or other alternatives, nor does it mention any 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, idempotentHint=true, and destructiveHint=false, so the safety and repeatability profile is known. The description adds the useful 'LOCAL mode only' constraint and the dual complete/incomplete behavior, which is partly redundant with the schema. It does not disclose error handling or side effects beyond what annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. It front-loads the action and resource, then adds a valuable scope qualifier. Every word earns its place.
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 two-parameter mutation with no output schema, the description provides the essential purpose and mode restriction. The schema and annotations fill in param details and behavioral hints. It lacks explicit error-handling or preconditions, but this is not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers both parameters (reminderId description and completed description with default), giving 100% coverage. The description itself adds no parameter-level semantics beyond what the schema already says. Since schema coverage is high, baseline of 3 is appropriate.
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 ('Marks') and resource ('reminder') with a clear state change ('complete or incomplete'). It distinguishes itself from siblings by focusing on the completion status specifically, and adds a scope constraint with '(LOCAL mode only)'. This is unambiguous and action-oriented.
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?
The purpose implies when to use the tool (to mark a reminder complete or incomplete), and the '(LOCAL mode only)' note provides a clear context and restriction. However, it does not explicitly mention alternatives like update-reminder or list-reminders, so it lacks a direct comparison.
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 idempotentHint=true, establishing the read-only safety profile. The description adds 'detailed' and 'specific' but does not disclose return format, error behavior, or what exactly constitutes 'detailed information'. With annotations covering core safety, a score of 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 verb and resource. It wastes no words and is immediately understandable.
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, single-parameter read tool with safety annotations, the description is fairly complete. It lacks explicit detail about the return value or handling of non-existent contacts, but those are not critical for a straightforward read operation. The absence of an output schema means some return info would help, hence a 4 rather than 5.
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 100%, and the parameter 'contactUrl' already has a clear description ('URL or ID of the contact (from list-contacts output)'). The tool description adds no additional parameter-level meaning, so the baseline 3 applies.
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 'Get detailed information about a specific contact' uses a specific verb ('get') and resource ('specific contact'), clearly distinguishing it from sibling tools like list-contacts (which lists all contacts) and search-contacts (which searches). The word 'detailed' suggests it provides more in-depth data than a list operation.
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?
The description implies usage when needing details on a known contact, and the parameter schema explicitly states 'from list-contacts output', giving a clear workflow context. However, it does not explicitly mention when not to use this tool or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds that search is by name/email/phone, which gives some matching behavior insight, but does not disclose pagination, result ordering, or whether matching is partial/fuzzy. This is modest additional value beyond annotations and schema, so 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, direct sentence with no filler. It is front-loaded with the verb and resource, making it easy to scan. Every word earns its place.
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 search tool with two parameters, an output schema, and clear annotations, the description is adequate. It does not need to explain return values since the output schema exists. The description covers the core purpose sufficiently, though it omits details about search nuance (e.g., partial matches) which are not critical for this 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 100%: both 'query' and 'count' have descriptions. The description's 'name, email, or phone' largely duplicates the query parameter description, adding no new semantics. Count's default and max are already in the schema. The description does not explain query syntax or result count behavior beyond what the schema provides.
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 'Search contacts by name, email, or phone', identifying the action (search), resource (contacts), and the specific fields searched. This distinguishes it from sibling tools like list-contacts (listing all) and read-contact (reading a specific contact), as well as search-reminders/search-emails for other resource types.
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?
The description implies usage context: use this tool when you need to find contacts by name, email, or phone. It is clear but does not explicitly state when to prefer list-contacts or read-contact instead, nor does it mention any exclusions or alternatives directly. However, the context is sufficiently clear from the phrase.
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 and idempotentHint, so the safety profile is known. The description adds that search covers title and content, but doesn't disclose other behavioral details like return format or pagination limits (though count is in schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, perfectly concise and front-loaded with the verb.
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?
Tool is simple with well-documented schema and annotations. Description adequately conveys the search behavior, though it doesn't explicitly mention return type (list of notes) or further nuances; still sufficient for a straightforward search tool.
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 coverage is 100% for both parameters. The description adds meaning to 'query' by specifying it searches title and content, which is beyond the schema's generic 'Search text (required)'.
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?
Clearly states a specific verb ('Search') and resource ('notes'), and specifies the search scope ('title or content'), distinguishing it from sibling search tools for emails/reminders.
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 (searching notes by text) but does not explicitly state when to use it over list-notes or read-note, nor mention alternatives 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 and idempotentHint, so the agent knows this is a safe, idempotent read. The description adds the specific output (URL and title) but does not disclose edge cases like behavior when Safari is not running or when no tab is active. Given the annotation coverage, this is a reasonable level of transparency, similar to the TDQS 4.3 calibration case.
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: 'Gets the URL and title of the current/active Safari tab.' Every word earns its place, with no redundant or missing information. It is appropriately concise for the tool's simplicity.
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 tool with no parameters, good annotations, and a clear return value (URL and title), the description is fully complete. The sibling tool list provides additional context for disambiguation. No output schema exists, but the description sufficiently explains what the agent can expect. The simplicity of the tool makes further detail unnecessary.
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 input schema has zero properties, so there are no parameters to describe. According to the rubric, a baseline of 4 is appropriate for zero-parameter tools. The description adds no parameter details, but none are needed since the tool takes no input.
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 function: 'Gets the URL and title of the current/active Safari tab.' The verb 'gets' and the specific resource ('current/active Safari tab') make the purpose obvious and distinguish it from sibling tools like list-safari-tabs or open-safari-url.
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 the current/active tab's URL/title) but does not explicitly mention alternatives or exclusions. It would be stronger if it noted that list-safari-tabs should be used for obtaining all tabs, but the context is generally clear from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint, openWorldHint, idempotentHint) already indicate the safe, non-mutating nature of the tool. The description adds the behavioral scope of 'all available', implying no filtering or restriction on the result set. This provides some context beyond annotations, though not extensive details like pagination or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant wording. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, clear annotations, and an existing output schema), the description is sufficiently complete for an agent to invoke it correctly. The only missing piece would be usage guidance, but that is not critical for this straightforward list operation.
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?
With zero parameters, the schema fully covers any parameter semantics. The description does not need to explain anything about inputs. This meets the baseline for no-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 uses the specific verb 'Lists' and the resource 'calendars' with 'all available' indicating scope. It clearly distinguishes from sibling list tools by naming the resource type. This fully conveys the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It implies usage when listing calendars is needed, but does not mention any exclusions or alternatives among the many sibling list tools. This is adequate but minimal.
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 idempotentHint=true, so the safety profile is covered. The description adds 'recent' scope and return content (contact names, last message preview), providing useful 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 a single, front-loaded sentence that directly states the tool's purpose and key output. No filler or redundant information.
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 one parameter and an output schema, the description is sufficient. It specifies the type of conversations, the 'recent' scope, and the output preview, covering the main context an agent needs.
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 fully describes the single 'limit' parameter (100% coverage), including default and constraints. The description adds no additional parameter semantics, so it relies on the schema, resulting in a baseline score.
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 identifies the resource as 'iMessage/SMS conversations', while specifying output details (contact names, last message preview). This distinguishes it from sibling tools like send-message or read-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 intended use case is implied by the function name and description, but there is no explicit guidance on when to use this tool versus alternatives like read-messages. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and repeatability. The description adds the 'LOCAL mode only' trait, which is beyond annotations and provides useful behavioral context. It does not disclose other behaviors like pagination or ordering, but given the annotations, the additional context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates core functionality and constraints without wasting words. It is front-loaded and easy to parse.
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?
The tool has no required parameters, a fully descriptive schema, and an output schema. The description covers the main purpose and the critical mode restriction. Return values are handled by the output schema, so no additional detail is needed. This is complete for a simple list tool with strong annotations.
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 covers all parameters with descriptions (100% coverage), so the schema already handles parameter semantics. The description's mention of 'specific list or all lists' aligns with the listName parameter but adds no new meaning beyond the schema. Baseline of 3 is appropriate.
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 ('Lists'), the resource ('reminders'), and the scope ('from a specific list or all lists'). It also includes the mode restriction ('LOCAL mode only'), which adds specificity and differentiates this tool from other reminder tools like 'search-reminders'.
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 reminders but provides no explicit guidance on when to choose this over alternatives such as 'search-reminders'. The 'LOCAL mode only' constraint is a clear exclusion for non-local modes, but no alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, destructive-safe write operation. The description adds useful context about local vs. cloud mode, but does not disclose behaviors like duplicate handling or idempotency, which is adequate given 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?
Two concise, front-loaded sentences. The first states the core action, and the second provides essential parameter guidance without unnecessary detail.
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 tool's simplicity, the description covers the action, storage modes, and parameter requirements. Missing details like return values are not critical since no output schema exists and creation tools typically return nothing or a simple confirmation.
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 coverage is 100%, so baseline is 3. The description adds value by clarifying that all fields are optional and recommending at least a name (displayName or firstName+lastName), guiding parameter usage beyond the schema.
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 it creates a contact in the user's address book, with specific details about local and cloud modes. This distinguishes it from sibling create tools (create-event, create-note) and other contact tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on minimum required input (pass at least a name) and suggests combining it with known fields. Does not explicitly state when not to use it, but the context is clear for creating contacts.
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 and idempotentHint, covering the safety and idempotency aspects. The description adds the 'LOCAL mode only' behavioral constraint and examples of account types, but does not disclose additional behaviors such as return format or pagination. This is similar to the calibration example where description added a scoping constraint but lacked richer 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 that is concise and front-loaded. It communicates the core function, provides examples in parentheses, and notes the mode restriction without any waste or 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 zero-parameter tool with an output schema available, the description is sufficiently complete. It covers what the tool lists, gives example account types, and notes the local-only constraint. The output schema presumably handles the return value details, so the description doesn't need to over-explain.
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 per the rubric the baseline is 4. The description does not need to explain parameter semantics, and the empty schema fully documents that no parameters are required.
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 function: 'Lists all contact accounts (iCloud, Google, Exchange, etc.)'. It uses a specific verb+resource construction and distinguishes from sibling tools like 'list-contacts' and 'list-contact-groups' by focusing on 'accounts' rather than contacts or groups. The 'LOCAL mode only' qualifier adds additional scope clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use: to list all contact accounts, with examples of account types. It also specifies a usage restriction via 'LOCAL mode only', implying it is not applicable in other modes. However, it does not explicitly mention alternatives or when-not scenarios, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. It adds useful context beyond annotations by specifying that the tool works in 'LOCAL mode only' and filters by account, which are behavioral traits not captured in structured metadata.
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 filler, front-loaded with the action and scope. Every part is informative: what it lists, from where, and the mode restriction.
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 one-parameter schema, read-only annotations, and presence of an output schema, the description covers the essential aspects for an agent to select and use the tool. The only minor gap is not elaborating on what 'LOCAL mode' entails, but that is sufficient for basic invocation.
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 input schema has 100% coverage, describing accountId as 'Optional account ID to filter groups by (from list-contact-accounts)'. The description's phrase 'from all accounts or a specific account' aligns with the parameter but does not add technical details beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lists' and clearly identifies the resource 'contact groups' with scope ('from all accounts or a specific account'). It distinguishes from sibling tools like list-contacts and list-contact-accounts by targeting contact groups, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to retrieve contact groups) and mentions 'LOCAL mode only', which is a usage restriction. The schema references list-contact-accounts as a source for accountId, providing some cross-tool guidance. However, it does not explicitly state alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds an important behavioral instruction—'IMPORTANT: Always confirm with user before sending'—which is not captured in the annotations. This clarifies the required confirmation step. The annotations already mark readOnlyHint=false, so the write operation is expected, and the description complements this without contradiction.
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 and a crucial warning. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema), the description covers the essential action and the confirmation requirement. It omits potential failure modes or return values, but for a straightforward send operation, this is not a significant gap.
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 covers all three parameters with descriptions (100% coverage), so the description adds no additional parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send an iMessage or SMS' with a specific verb and resource. It distinguishes itself from siblings like send-email by specifying the messaging format (iMessage/SMS).
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?
The description provides clear context (iMessage/SMS) but does not explicitly mention when to use this tool over alternatives like send-email. However, the medium is distinct enough to infer usage, and there are no exclusions or conditions 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?
The description adds meaningful behavioral context beyond the annotations by explaining what LOCAL and CLOUD mean (AppleScript/macOS apps vs iCloud protocols). While it does not detail side effects or return values, the annotations (idempotentHint: true, destructiveHint: false) already provide a safety profile, and the description aligns with the readOnlyHint being false (a state-changing operation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It contains no wasted words and clearly communicates the tool's purpose in a compact format.
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 1-parameter tool with a well-documented enum, the description is largely complete. It explains the modes and the tool's function, though it does not explicitly describe the result of the switch or any side effects. Given the low complexity and rich schema, this is sufficient.
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 already provides 100% coverage for the 'mode' parameter with an enum and detailed property description. The tool description does not add meaningful information about the parameter beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: switching between LOCAL and CLOUD modes. It uses a specific verb ('Switch') and resource ('mode'), and distinguishes this tool from siblings by describing the exact modes involved (AppleScript/macOS vs iCloud).
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?
The description gives clear context that this tool is for toggling between two modes, with no ambiguity about when to use it. However, it does not explicitly mention alternatives or exclusions, though none are obvious given the sibling list. This is a clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is clear. The description adds behavioral context by specifying the default folder (inbox) and the folder parameter's scope, which goes beyond the annotations. It does not disclose details like pagination or ordering, but the output schema likely covers return structure.
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 core behavior, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 two optional parameters, an output schema, and strong annotations (read-only, idempotent), the description covers the essential context: the action (list), the subject (emails), and the key default (inbox). The output schema handles return values, and annotations handle safety, making the description sufficient.
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 100%, so the parameter descriptions already document count and folder. The description adds value by explicitly stating the default folder as 'inbox', which is not present in the folder property's description. This enriches parameter understanding beyond the schema.
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 is specific: 'Lists emails from a folder (default: inbox)' clearly identifies the verb (List), resource (emails), and scope (folder-based). It distinguishes from sibling tools like read-email (single email) and search-emails (filtered search) by stating the folder-based listing behavior.
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 listing emails from a folder) but does not explicitly state when not to use it or mention alternatives such as search-emails for filtered queries. The guidance is derived from the tool's name and behavior rather than stated directly.
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, openWorldHint, and idempotentHint, so the agent knows this is a safe, read-only operation. The description adds value by specifying the returned fields (title, start/end times, ref handle) and the relationship to update/delete tools. It does not contradict annotations and provides context beyond the structured hints.
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 sentences, front-loaded with the core action, and contains no redundant or irrelevant content. It efficiently conveys the tool's purpose and key behavioral details.
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 two optional parameters, an output schema, and comprehensive annotations, the description sufficiently covers purpose, returned data, and linkage to sibling tools. It does not need to elaborate on return values or error handling given the output schema exists.
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 100% for both 'count' and 'daysAhead', including defaults and maximums. The description's mention of the look-ahead window (30 days default, up to 365) aligns with the schema and adds no new information. Since the schema fully documents parameters, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists upcoming calendar events within a configurable look-ahead window. The verb 'lists' and resource 'calendar events' are specific, and it naturally distinguishes itself from sibling tools like list-calendars (which lists calendars) and event mutation tools (create/update/delete).
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?
The description provides clear usage context by explaining the look-ahead window and that returned ref handles are used by update-event and delete-event. It implicitly guides when to use this tool (to get event handles for mutation), though it does not explicitly state when not to use it or mention alternatives like list-calendars.
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 and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context by specifying the search scope ('name or body') and the LOCAL mode restriction, which goes beyond the structured annotations. No contradiction is present.
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, compact sentence that front-loads the key verb and resource. Every word adds value: the search subject, the search fields, and the mode restriction. No redundant or filler content.
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 search tool with two parameters and no output schema, the description is largely complete. It covers what is searched and the mode limitation. However, it does not explicitly state what the response contains (e.g., matching reminders), which is a minor gap given the absence of an output schema.
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 already describes both parameters with 100% coverage, setting a baseline of 3. The description enhances understanding by clarifying that the query matches against both 'name or body', which gives semantic meaning to the 'query' parameter beyond the schema's generic 'Search text'.
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 identifies the tool as a search operation ('Search reminders') with a specific scope ('by text in name or body'). This distinguishes it from sibling tools like list-reminders and other search tools (search-notes, search-emails), and the 'LOCAL mode only' qualifier adds a unique constraint.
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?
The description provides clear context for when to use the tool (searching reminders by text) and includes a critical mode restriction ('LOCAL mode only'). However, it does not explicitly contrast with alternatives like list-reminders or state when not to use it, leaving some ambiguity for an 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?
Annotations already indicate destructive and non-read-only behavior. The description adds valuable context beyond annotations: the deletion is permanent, irreversible ('no undo'), and recommends confirmation via read-contact. This exceeds the baseline annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, followed by essential usage guidance. Every word earns its place; no redundant or vague phrasing.
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, one parameter, and existing annotations, the description fully covers purpose, usage, and irreversible consequences. Nothing critical is missing for an agent to safely invoke this tool.
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 coverage is 100%, so the parameter is fully documented. The description adds extra semantic context by specifying that the handle comes from list-contacts or search-contacts and advising read-contact confirmation, which enriches the bare schema description.
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 ('deletes'), resource ('contact'), and scope ('user's address book'), clearly distinguishing it from sibling tools like delete-event or delete-reminder. The permanence is also communicated, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: use the handle from list-contacts or search-contacts, and confirm with read-contact first. It doesn't explicitly exclude alternatives, but the context is clear enough for an agent to know when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds meaningful behavioral context: a 50-contact limit per call, pagination implication, and the presence of a handle useful for downstream operations. This goes beyond annotations without contradicting them.
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?
Two sentences, no filler. The first sentence immediately states the core function, the second provides a useful alternative. Every clause earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description only needs to convey purpose, usage, and key constraints. It covers the pagination limit, the handle for dependent tools, and the sibling alternative. For a simple list tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema itself documents count's range and default (default: 25, max: 50). The description mentions 'up to 50 per call,' which reinforces the limit but does not add significant new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Lists contacts from the user's address book.' It also distinguishes itself from the sibling tool search-contacts, which filters instead of paging, and implies the output format includes a handle for read-contact and delete-contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'For a targeted lookup, search-contacts filters by name, email or phone instead of paging through the full list.' This directly tells the agent when to choose this tool versus an alternative, which is exactly what the dimension requires.
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 idempotentHint=true, covering safety and idempotency. The description adds the 'LOCAL mode only' constraint, providing useful context about runtime behavior beyond the annotations. 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?
A single, front-loaded sentence conveys the essential information without any waste. Every word earns its place.
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, parameterless, read-only listing tool with an output schema present, the description is complete. The 'LOCAL mode only' qualifier is the only important constraint, and it is included.
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 schema coverage is trivially 100%. No parameter semantics are needed, so the description does not need to compensate; the baseline of 4 is appropriate.
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 ('Lists') and resource ('all folders in Notes.app'), clearly distinguishing this from sibling tools like list-notes (notes vs folders) and list-folders (which lacks the Notes.app scoping). The 'LOCAL mode only' qualifier further narrows the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context and an explicit exclusion: it only works in LOCAL mode. However, it does not explicitly name alternatives or explain when to prefer this over list-folders or other listing tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the 'LOCAL mode only' constraint, which is useful behavioral context beyond the annotations. Since an output schema exists, the lack of return-format details is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence with no filler. It fully conveys the tool's purpose and scope in 9 words.
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 tool with no parameters and an output schema, the description is complete. It specifies the resource, scope, and mode, and there are no hidden behavioral requirements to disclose.
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?
There are zero parameters, so the baseline of 4 applies. The description adds no parameter-specific details, but none are needed.
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 ('Lists') and resource ('all reminder lists from Reminders.app'), and adds a scope qualifier ('LOCAL mode only') that clearly distinguishes it from related tools like 'list-reminders' and 'search-reminders'.
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?
The phrase 'LOCAL mode only' gives clear context that this tool operates on local Reminders.app data, implying it should not be used in iCloud or other modes. It does not name explicit alternatives, but the purpose is straightforward for a read-only listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, letting the agent know this is a safe read operation. The description adds the behavioral detail that all windows are included, which goes beyond the annotations. No contradictions are present.
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 immediately states the tool's purpose and scope. There is no redundant information, and it is perfectly 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?
For a zero-parameter tool with a rich output schema and strong annotations, the description fully covers the necessary information. It clearly states what the tool does, which is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The baseline for zero-parameter tools is 4, and the description does not need to add parameter-specific details.
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 verb 'Lists' with the resource 'all open tabs in Safari across all windows', clearly indicating what the tool does and its scope. It distinguishes itself from sibling tools like open-safari-url and close-safari-tab by focusing on enumeration of all tabs.
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?
The description provides clear context that this is the tool for enumerating all open tabs. It does not explicitly mention alternatives or when not to use it, but the scope is self-evident given the tool name and context of other Safari-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only, open-world, and idempotent behavior. The description adds valuable context beyond those annotations: filters combine as AND, only one folder is searched, and the result includes the ref handle that read-email and mark-as-read consume. No contradiction with 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 consists of two concise sentences. The first covers the core purpose and filter behavior, the second explains the output format and interoperability. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With complete schema coverage, rich annotations, and an output schema, the description still adds significant context: folder scope, AND logic, and cross-tool compatibility. This is sufficient for an agent to correctly select and invoke the tool.
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 covers 100% of parameter descriptions, setting a baseline of 3. The description adds meaningful semantics by stating that all filters combine as AND, which is not explicitly stated in individual parameter descriptions. It also links the output to other tools, but does not deeply elaborate on parameter syntax or formats.
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 that the tool searches emails with specific filters (text, sender, subject, unread state) and scopes to one folder (default inbox). This distinguishes it from list-emails, which lists emails, and search-notes, which searches a different resource.
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?
The description provides clear context: it searches a single folder with an AND combination of filters, and references list-emails for output format. It implicitly communicates when this tool would be used for filtered email retrieval, but it does not explicitly exclude alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing two distinct operational modes: cloud mode (SMTP, returns message ID) and local mode (Mail.app, plain text only, no ID). It also notes the immediate, no-draft behavior. These are significant behavioral details not present in the annotations, which only indicate non-read-only, non-idempotent, and non-destructive traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each essential: the first states the core function, the second explains mode differences and return behavior, and the third warns about the lack of a draft. No filler words; information is front-loaded and efficiently organized.
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 moderate complexity (6 parameters, no output schema), the description covers all critical operational aspects: recipients, CC/BCC, HTML, mode-specific behavior, return values, and the immediacy of send. It sufficiently prepares the agent to invoke the tool correctly without needing external documentation.
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 input schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by clarifying comma-separated recipients and especially by noting that local mode only sends plain text, which affects how isHtml and body should be interpreted. This helps the agent understand parameter behavior beyond the schema.
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 purpose: 'Sends an email immediately from the user's account to one or more comma-separated recipients.' It specifies the verb (sends), resource (email), and qualifies how recipients are specified. It also differentiates from sibling tools like send-message by explicitly focusing on email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool (immediate email sending) and importantly warns about the lack of a draft step, which helps with decision-making. It does not explicitly mention alternatives like send-message for chat, but the tool name and scope make the intended use clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses partial-update behavior and specifies that in cloud mode, recurrence, invitees, and alarms are preserved via CalDAV property-merge. It also flags the feature as experimental with live round-trip unverified. This goes well beyond the annotations, which only indicate non-read-only, idempotent, and non-destructive characteristics.
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 sentences, with the core action front-loaded in the first sentence. It then provides the single most important behavioral nuance and a risk caveat, with no redundant information.
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 complexity as an update operation with mode-specific behavior, the description covers purpose, update semantics, cloud-mode preservation, and experimental status. Without an output schema, this is sufficient for correct invocation. The only omission is explicit local mode behavior, but that is handled by the eventUrl parameter description.
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 documents all six parameters with descriptions, covering 100% of parameter semantics. The description adds the crucial partial-update rule: only fields passed are changed, which is not evident from the schema alone. This clarifies how omitted optional parameters behave.
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: 'Updates an existing calendar event.' This distinguishes it from create-event and delete-event by focusing on modifying an existing entity. The additional note about partial updates further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate use case: modifying fields of an existing calendar event. It does not explicitly name alternatives, but the context is evident from the sibling tool list, and the partial-update statement guides when to use it. The cloud-mode note provides mode-specific context, but no explicit when-not-to-use.
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/MrGo2/icloud-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server