Apple-MCPs
Server Quality Checklist
Latest release: v1.0.4
- Disambiguation2/5
Many tools have direct duplicates or near-duplicates across the apple_* wrappers and the delegated domain tools (e.g., apple_open_application vs system_open_application, apple_get_focus_status vs system_get_focus_status, apple_send_message_interactive vs messages_send_message). The delegated tool descriptions are all identical boilerplate, forcing agents to rely on names alone, and several apple_preview_* vs apple_create_* pairs add further ambiguity.
Naming Consistency4/5Tool names are overwhelmingly snake_case with a domain_verb_noun pattern (mail_search_messages, notes_create_note, system_get_battery), which is predictable. The main deviation is the mixed apple_* meta-tool prefix alongside domain prefixes, and a few inconsistent helpers like apple_suggest_* fallback tools and interactive variants, but the overall pattern is still readable.
Tool Count1/5184 tools is far beyond any reasonable single MCP surface, even for an aggregated Apple ecosystem server. This is an extreme mismatch with the typical well-scoped server size, and the count creates significant selection and maintenance burden for agents.
Completeness4/5The set offers broad CRUD and lifecycle coverage across mail, calendar, reminders, notes, contacts, messages, files, system, maps, and shortcuts, including health checks and undo/audit support. Minor gaps exist, such as no file write/edit tool and limited mail attachment handling, but the core workflows are well covered.
Average 2.2/5 across 184 of 184 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 25 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.
Add a glama.json file to provide metadata about your server.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include openWorldHint=true, idempotentHint=false, and destructiveHint=false, but the description adds no behavioral context such as whether this creates a draft, opens a compose window, requires permissions, or has side effects. The description's only content is organizational boilerplate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but brevity here is under-specification, not conciseness. The single sentence conveys no actionable information and merely restates the tool's name and provenance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters, no schema descriptions, and a rich set of sibling mail tools, this description is severely incomplete. It does not explain what a 'draft' means in this context, whether the email is sent or saved, or how this differs from mail_send_message. An agent has no basis for invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the seven parameters. The field names are somewhat self-explanatory, but the description itself adds no semantic value, and optional fields like from_account, attachments, and cc remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and says it is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP. It does not state what the tool actually does—composing a mail draft is left entirely to inference from the name. There is no verb, resource, or behavior specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool, what it is for, or when to prefer alternatives like mail_send_message or mail_reply_message. An agent cannot determine the intended workflow from this text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. However, the description adds zero behavioral context beyond that: it does not mention result limits, matching behavior, ordering, or what happens with no results. The description's entire content is a plumbing note about delegation via Apple-Tools-MCP.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically short, but this is under-specification rather than conciseness. The single sentence only passes through the tool name and domain context, wasting the only opportunity to convey semantics in an otherwise empty description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 2 parameters and 0% schema coverage, the description is entirely inadequate. An agent cannot determine what is being searched, what inputs are expected, or what the output contains. The output schema exists but the description adds nothing to make the tool safely or correctly invocable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention either parameter. The description must compensate for the schema's lack of parameter documentation, but it provides nothing about what 'query' means, whether it is a substring or prefix match, or how 'limit' affects the returned results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it merely restates the tool name and its delegation origin ('Delegated Apple domain tool 'contacts_search_contacts' exposed through Apple-Tools-MCP'). It does not state that the tool searches contacts, what fields it searches, or how it differs from siblings like contacts_list_contacts or contacts_resolve_message_recipient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to use this tool versus contacts_list_contacts, contacts_get_contact, or contacts_resolve_message_recipient, nor does it mention any constraints or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral information beyond what the annotations already state. It does not mention scope, side effects, failure conditions, permission requirements, or any operational nuance. The annotation contradiction flag is false because nothing contradicts, but the description itself is empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but shortness is under-specification, not conciseness. A single sentence that only echoes the tool name provides no informative structure and fails to earn its place as a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema and a large sibling list providing useful context, the description is completely inadequate for a tool with two required parameters and no parameter documentation. There is no functional explanation, no usage context, and no relationship to sibling tag-management tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does nothing to explain the 'path' or 'tags' parameters. Both are required, yet their meanings, formats, and behavior are entirely undocumented. The description should compensate for the schema gap but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it merely restates the tool name 'files_remove_tags' and says it is 'exposed through Apple-Tools-MCP'. It never states a verb, resource, or action, so an agent cannot determine what the tool actually does from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 or when to prefer it over alternatives. Sibling tools like files_add_tags, files_set_tags, and files_get_tags exist, but the description gives no indication of how files_remove_tags fits relative to them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only openWorldHint=false, idempotentHint=false, and destructiveHint=false. The description adds no behavioral context beyond those, such as what 'reveal in finder' does, whether it requires Finder permissions, or whether it opens a window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but shortness here is under-specification rather than conciseness. It contains no front-loaded functional information and fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has only one parameter and an output schema exists, the description is far too incomplete for an agent to know what the tool does, when to invoke it, or what side effects to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the required 'path' parameter at all. The agent is left to infer that 'path' is a file path solely from its name, with no clarification of format, scope, or meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and says it is 'Delegated Apple domain tool ... exposed through Apple-Tools-MCP.' It provides no verb, no resource, and no behavior such as revealing a file in Finder. This is essentially a tautology with wrapper metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool. It does not mention alternatives like apple_reveal_in_finder or files_open_path, nor any conditions that would select this tool over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details about side effects, reversibility, permission requirements, or what happens to the source mailbox. The annotations are sparse and the description adds no contextual value beyond them, nor does it explain the 'delegated' nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification, not concise value. The single sentence spends its words restating the tool name and platform wrapper, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating mail operation with an output schema and multiple contextually significant parameters, the description is essentially empty. It fails to mention the operation, target semantics, source behavior, or any conditions for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate at all. It does not explain message_id, target_account, or target_mailbox semantics, cross-account moving, or the meaning of optional versus required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and its category ('Delegated Apple domain tool') without stating what it does. There is no verb+resource relationship, no mention of moving a message, and no distinction from mail_archive_thread or mail_mark_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. Nothing explains the difference between moving a message, archiving it, deleting it, or marking it, despite many mail-related siblings existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (openWorldHint=false, idempotentHint=false, destructiveHint=false) carry the only behavioral signal, and the description adds nothing beyond them. It does not disclose whether this is a read-only URL builder, whether delegation implies network dependency, or what the output link contains. The description does not contradict the annotations, so no contradiction is flagged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short, but brevity without information is under-specification, not conciseness. The sentence does not earn its place because it solely repeats the tool name and adds no operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters and 0% param description coverage, the description is entirely inadequate. It does not explain the tool's function, when to use it, how parameters behave, or what the output schema represents. The presence of an output schema is the only mitigating factor, but the description never even states what the tool produces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's silence, but it provides no parameter explanation at all. Origin, destination, and transport are only known through their names and defaults ('driving'), forcing the agent to infer meaning. The description fails to clarify parameter format, constraints, or how transport values map to map-link behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Delegated Apple domain tool 'maps_build_maps_link' exposed through Apple-Tools-MCP,' merely restates the tool name and the transport mechanism. It never states that the tool builds an Apple Maps link or URL, leaving the agent to guess functionality from the name and parameter names. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool. With siblings like maps_open_directions_in_maps, apple_maps_get_directions_strict, and maps_get_directions available, the description gives no basis for choosing this over alternatives. An agent cannot tell whether to build a link, fetch directions, or open the Maps app.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, but the description itself adds no behavioral context. It does not explain whether directions are returned, how they are formatted, or any other behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but it is under-specification rather than conciseness. Every word is boilerplate and adds no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having required parameters, a default value, an output schema, and numerous siblings, the description provides no information about return values or correct invocation. The tool is completely underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the parameters. Agents must infer that origin and destination are locations and transport is a travel mode, with no help from the text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and its MCP exposure; it never states what the tool does. This is a tautology with no functional content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 siblings like maps_open_directions_in_maps or apple_maps_get_directions_strict. No context is provided for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral insight beyond what the annotations already provide. It says nothing about side effects, such as opening the Maps app or launching navigation, and the annotations (openWorldHint, idempotentHint, destructiveHint) are minimal. There is no contradiction, but there is also no meaningful behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. Every word spent on 'Delegated Apple domain tool' and 'exposed through Apple-Tools-MCP' could have been replaced with actual functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich sibling context with multiple maps tools and a 3-parameter schema, the description is completely inadequate. It fails to explain the behavior, the required input semantics, or how this tool differs from closely related direction tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the parameters but does not. It offers no guidance on what 'destination' or 'origin' should look like, nor what values 'transport' accepts beyond the default 'driving'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name in quotes ('Delegated Apple domain tool 'maps_open_directions_in_maps' exposed through Apple-Tools-MCP') and gives no indication of what the tool actually does. It lacks a specific verb and resource, and does not distinguish this from sibling direction-related tools like maps_get_directions or apple_maps_get_directions_strict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. No conditions, exclusions, or mention of sibling tools are provided, so an agent cannot determine whether to choose this over maps_get_directions or maps_build_maps_link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits whatsoever — it does not mention filtering behavior, pagination, return format, or any side effects. The readOnlyHint and idempotentHint annotations are the only useful safety signals, and the description adds nothing beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, nominally short, but it is under-specified rather than concise. It earns no place because it contains no functional information — it is packaging text, not tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 4 parameters, the description explains nothing about what the tool does, when to invoke it, or what its parameters control. An agent would have to rely purely on the tool name and annotations, which is completely inadequate for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 4 parameters (limit, offset, chat_id, message_id), the description was required to compensate but mentions none of them. An agent cannot infer the meaning of any parameter from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Delegated Apple domain tool messages_list_attachments exposed through Apple-Tools-MCP', is a tautology that merely restates the tool name and adds infrastructure boilerplate. It never states the verb+resource action (listing attachments from messages) with any functional content. Even the title is just the name expanded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus any of its siblings such as messages_get_message, messages_search_messages, or messages_list_conversations. No use cases, exclusions, or alternative routing are mentioned anywhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds zero behavioral information beyond the annotations. It does not state that the operation modifies an existing folder, whether it is reversible, what happens if the folder does not exist, or any side effects. With annotations present, the bar is lower, but the description still contributes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. The single sentence restates the tool name and framework and carries no useful information, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description completely fails to explain the tool's purpose, required parameters, or relationship to sibling tools. For a mutation operation like renaming a folder, an agent has no basis for correct invocation or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It never explains that folder_id identifies the target folder or that folder_name is the new name. The parameter names are self-evident, but the description provides no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it repeats the tool name and states it is 'exposed through Apple-Tools-MCP' without saying what the tool actually does. There is no verb, resource, or outcome described beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that this renames an existing folder, distinguish it from notes_create_folder or notes_delete_folder, or note any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits beyond the annotations. It does not mention side effects, idempotency, required permissions, or any consequences of creating a reminder. The annotations provide minimal hints, but the description itself adds no transparency value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. It contains no useful content and fails to earn its place; a single tautological sentence is not effective structuring.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 9 parameters, an output schema, and a large set of sibling tools, this description is completely inadequate. It does not help the agent understand creation semantics, required list context, date formatting, or relationship to other reminder tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter information. The agent gets no help understanding title, list_id, due_date, priority, or other fields beyond raw schema names. This is a significant gap for a tool with 9 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it repeats the tool name and states it is an exposed Apple tool without saying what it does. The agent must rely on the title and schema to infer that a reminder is being created. No specific verb, resource, or effect is described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. Sibling tools such as reminders_create_list, reminders_update_reminder, or apple_create_reminder_with_defaults are not mentioned, so the agent cannot distinguish appropriate invocation contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits beyond the annotations. It does not describe update semantics, whether missing fields are preserved or cleared, whether values like null reset fields, or what side effects occur. With annotations present but limited, and a generic description, the agent receives no useful behavioral context. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity here is under-specification rather than efficient structure. A single boilerplate sentence saying the tool is 'exposed through Apple-Tools-MCP' carries no informative content and fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter mutation tool with no schema descriptions and an output schema, the description is severely incomplete. It does not explain which fields are updatable, whether the update is partial or full replacement, how reminder_id is used, or what the return value represents. The agent cannot safely invoke this tool based on the provided description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining what the 10 parameters mean or how they relate to updating a reminder. It does neither. The agent is left with raw parameter titles like 'Due Date' and 'Priority' and no guidance on formats, units, or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a pure restatement of the tool name and domain: 'reminders_update_reminder exposed through Apple-Tools-MCP.' It provides no verb-plus-resource explanation of what the tool actually does. An agent must infer from the name alone that it updates a reminder, which is tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool, when not to use it, or how it compares with sibling tools such as reminders_create_reminder, reminders_complete_reminder, or reminders_delete_reminder. The description offers no decision-relevant context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Aside from annotations indicating non-idempotent, non-destructive behavior, the description discloses nothing about how the tool behaves. It does not mention whether it activates the target application, requires accessibility permissions, waits for UI updates, or affects the frontmost app. The annotations carry the only behavioral signal, and the description adds no value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is short because it is an empty wrapper, not because it is efficiently written. It uses one sentence to say nothing meaningful, which is under-specification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a GUI automation tool with three parameters, no parameter descriptions, and no usage guidance, a one-sentence delegation notice is severely incomplete. Even with an output schema present, the agent lacks the semantic context needed to construct a valid menu_path or decide when this tool is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no explanation of menu_path, bundle_id, or application. The agent must rely solely on parameter names and the title. This is insufficient for a tool whose required parameter is a multi-step menu path array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only says the tool is a delegated Apple domain tool exposed through Apple-Tools-MCP, which merely restates the tool's name and wrapper context. It does not state what clicking a menu path accomplishes, which application or system behavior it affects, or how it differs from sibling GUI tools like system_gui_click_button.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 instead of system_gui_list_menu_bar_items, system_gui_press_keys, or system_gui_choose_popup_value. The description provides no selection criteria, prerequisites, or exclusions, leaving the agent to guess from the parameter names and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits. While annotations exist, they do not clarify the runtime effect of pressing keys, whether the action targets the frontmost application or a specified bundle_id, or whether any side effects such as focus changes or app navigation may occur. The description adds zero 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. It spends its only sentence on generic MCP routing boilerplate instead of tool-specific information. Every sentence should earn its place, and this one does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, this is a GUI automation tool that manipulates keyboard input. The agent needs to know what the key parameter accepts, how modifiers are formatted, what bundle_id and application do, and what the function returns. None of that is present, making the description inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for explaining parameters, but it explains none of them. The four parameters (key, bundle_id, modifiers, application) remain entirely undocumented in terms of their meaning, allowed values, or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a boilerplate wrapper: 'Delegated Apple domain tool ... exposed through Apple-Tools-MCP.' It restates the tool name without explaining what pressing keys does, what resource it acts on, or how it differs from sibling tools like system_gui_type_text. This provides almost no functional meaning to an agent selecting the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives. There is no mention of which applications or contexts support key pressing, no note about frontmost app targeting, and no comparison to sibling GUI tools such as system_gui_type_text or system_gui_click_button.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral information beyond the annotations. It does not disclose that this launches an application, whether it is safe, what side effects it has, or whether it requires permissions. With no coverage from the description, the agent cannot infer operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is short but under-specified; it is not concisely informative. It restates the tool name and adds a generic 'exposed through Apple-Tools-MCP' wrapper, which does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description is completely inadequate for a two-parameter tool. There is no explanation of what the tool does, when to invoke it, or how the optional parameters relate. An agent could not confidently select or call this tool based on the provided context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to bundle_id or application. Both parameters are optional and nullable, but the description does not explain how to choose between them, whether one supersedes the other, or what values are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it only says the tool is 'Delegated Apple domain tool system_open_application exposed through Apple-Tools-MCP.' It never states that the tool opens an application, what inputs it accepts, or what effect it has. It does not distinguish this from the sibling apple_open_application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. Sibling tools like apple_open_application, files_open_path, and system_list_running_apps exist, but the description gives no conditions, exclusions, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits: no mention that this modifies Finder UI state, whether it requires special permissions, whether the change is persistent, or what the side effects are. The annotations only declare openWorldHint, idempotentHint, and destructiveHint as false, so the description carries the full burden and fails to provide any useful behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but this is under-specification rather than effective conciseness. It contains only a name restatement and a generic statement about being exposed through Apple-Tools-MCP, neither of which earns its place as useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that mutates a Finder UI setting, the description is severely incomplete. It does not define what the Finder path bar is, what enabling or disabling it does, or how an agent should determine the desired value. Even though an output schema exists, the missing behavioral and parameter semantics make this definition inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the single 'enabled' boolean parameter has no schema description. The tool description does not explain what 'enabled' means, what value to pass, or what the resulting behavior would be. The description adds no meaning beyond the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name ('system_set_finder_path_bar') and says it is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP. It never states what the tool actually does, such as showing or hiding the Finder path bar. This is essentially a tautology with no actionable purpose information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The sibling list includes similar system_set_* tools such as system_set_finder_status_bar and system_set_show_hidden_files, but the description provides no conditions, exclusions, or selection criteria to differentiate them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information at all. Annotations say idempotentHint is false and destructiveHint is false, but the description does not explain persistence, side effects, permissions, or what toggling this setting changes. For a setter with no idempotency guarantee, the agent is left without key 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not usefully concise; its only sentence spends itself on boilerplate about being an exposed delegated tool. Under-specification masks as conciseness because no actual information is delivered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has a single boolean parameter and an output schema, the agent cannot tell what setting is being changed, whether it is per-user or global, whether it requires permissions, or what a successful invocation entails. The description is inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Scema description coverage is 0%, so the description must carry parameter meaning, but it does not. The single required boolean 'enabled' is never explained, such as whether true shows the status bar or hides it. The description adds no value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name in a generic wrapper: 'Delegated Apple domain tool system_set_finder_status_bar exposed through Apple-Tools-MCP.' It never states the actual action, effect, or scope, so it is effectively a tautology. It also does not distinguish this tool from siblings like system_set_finder_path_bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, what prerequisites exist, or how it relates to alternatives such as system_get_finder_settings or system_set_finder_path_bar. The description provides no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits at all. It does not state that the tool modifies a system setting, what the enabled parameter does, whether the change is user-visible immediately, or any side effects. The annotations only provide weak signals (not idempotent, not destructive, closed world), and the description adds nothing beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but its single sentence is boilerplate about being 'exposed through Apple-Tools-MCP' rather than useful content. It is under-specified rather than genuinely concise, and no sentence earns its place by informing tool selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has only one parameter and an output schema, the description still leaves the agent unable to understand the tool's effect, the meaning of enabled, or how this system-set tool relates to sibling tools. An agent would have to rely entirely on the tool name and schema, which is insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description makes no attempt to explain the enabled parameter. The schema only gives the parameter name and boolean type, so the agent cannot determine whether true means 'show hidden files' or 'hide hidden files' or what scope the setting applies to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is purely tautological: 'Delegated Apple domain tool system_set_show_hidden_files exposed through Apple-Tools-MCP' restates the tool name without adding a verb, resource, or effect. It does nothing to distinguish this tool from its siblings, such as system_set_show_all_extensions or system_set_finder_path_bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, when not to use it, or what alternatives might be more appropriate. The sibling list contains related system-setting tools, but the description gives the agent no basis for choosing among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. It does not explain what the setting affects, whether it requires permissions, whether it applies globally, or what happens when 'enabled' is toggled. It simply restates the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. It contains no useful information beyond the title/name, so brevity is achieved by omitting substance rather than by prioritizing relevant 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?
The tool is simple, with one boolean parameter, and the name suggests a Finder preference about showing file extensions. However, the description does not confirm the domain, the current setting behavior, or the semantics of 'enabled', leaving meaningful gaps for an agent deciding whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the 'enabled' boolean parameter. The agent is left to guess the meaning of true/false and the exact effect on system settings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it merely restates the tool name as 'system_set_show_all_extensions' and labels it a 'Delegated Apple domain tool' without saying what the tool actually does. No verb, resource, or effect is described beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool vs alternatives. The sibling list contains many other system_set_* tools, but the description does not clarify which Finder or system setting this one controls or how it differs from tools like system_set_show_hidden_files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only openWorldHint=false, idempotentHint=false, and destructiveHint=false, but the description adds no behavioral context beyond that. It does not mention that creating an event is a side-effecting write, that it may require calendar permissions, or what happens on duplicate or conflicting events. No additional behavioral traits 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. Its only sentence is generic boilerplate that could apply to almost any Apple domain tool, so it does not earn its place. There is no functional content to structure or front-load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, including required ISO datetime strings, calendar_id, and recurrence, the description is completely inadequate. The presence of an output schema does not compensate for the total absence of behavioral, parameter, and usage guidance. An agent cannot reliably decide to invoke this tool from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings, formats, or relationships. It does none of this. The parameter names like start_iso, end_iso, recurrence, and calendar_id are left entirely self-explanatory, and the description adds zero semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name and title ('calendar_create_event' / 'Calendar Create Event') and adds only the boilerplate phrase 'Delegated Apple domain tool ... exposed through Apple-Tools-MCP.' It does not state what the tool does—that it creates a calendar event—nor does it distinguish itself from close siblings like calendar_update_event or calendar_delete_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use calendar_create_event versus alternatives such as calendar_update_event, calendar_delete_event, or calendar_list_events. No prerequisites, exclusions, or alternative selection criteria are provided. An agent must infer all usage context from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond the tool name. Annotations are sparse (destructiveHint is false, but there is no readOnlyHint), and the description does not clarify whether forwarding creates a new message, modifies the original, requires permissions, or has side effects. This leaves the agent without essential behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence, which is short, but it contains no useful substance—it simply restates the name and mentions the MCP exposure. This is under-specification rather than effective conciseness, so the sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema and sibling context available, the description omits the core purpose, behavior, and parameter meaning. For a tool with four parameters and no schema-level descriptions, this definition is far too incomplete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero explanation of the parameters (message_id, to, body, from_account). The agent must rely solely on raw parameter names and types, with no guidance on formats, semantics, or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it only restates the tool name ('mail_forward_message') and notes that it is exposed through Apple-Tools-MCP. It does not state what the tool does, what resource it acts on, or how it differs from related mail tools. The tool name itself carries the only real meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 such as mail_reply_message, mail_send_message, or mail_compose_draft. No context, conditions, or exclusions are provided, so an agent is left to infer the appropriate use case entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses zero behavioral traits. With no readOnlyHint and only idempotent/destructive hints that are all false, the description carries the full burden of explaining side effects, permissions, or return behavior, but it says nothing. An agent is left completely in the dark about what invoking this tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the single sentence is boilerplate that merely restates the tool's name and exposure mechanism. It is under-specified, not concise in a useful way. No meaningful information is front-loaded or otherwise presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with four parameters, a required folder_id, and no behavioral disclosure, the description is severely incomplete. It does not explain what creating a note involves, what the output is, or what constraints apply. The rich sibling list only makes the lack of context more apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings or relationships, but it does not. The schema provides raw names and types (title, folder_id, body_html, tags), yet the description adds no semantic value. This is a complete failure to clarify parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only repeats the tool name in a wrapper phrase: 'Delegated Apple domain tool 'notes_create_note' exposed through Apple-Tools-MCP.' It states no verb, no resource, and no action the tool performs. An agent cannot tell what this tool does beyond what the name itself implies.
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 notes_update_note, notes_append_to_note, or notes_create_folder. The name hints at creating a note, but the description offers no context, prerequisites, or exclusions. This is effectively no usage guidance.
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 annotations already declare destructiveHint=true and idempotentHint=false, so the agent knows the operation is destructive. However, the description itself adds no behavioral context beyond what annotations already provide, such as irreversibility, cascading effects, or permissions. It does not contradict the annotations, so it is not scored 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is shortened to the point of emptiness. It contains no functional content and is better characterized as under-specification than as useful conciseness. A concise effective description would state the delete action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity and the presence of an output schema, an agent cannot learn from the description what the tool does. The name and annotations hint at deletion, but the description itself lacks the minimal purpose statement needed to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain note_id and any constraints. It does not mention the parameter at all; the only clue is the schema property title 'Note Id'. The description provides zero compensatory semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it restates the tool name and says it is exposed through Apple-Tools-MCP. It never states that the tool deletes a note, and no operational verb or resource is described beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 over alternatives. Sibling tools like notes_update_note and notes_delete_folder imply related operations, but the description gives no criterion for choosing this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (openWorldHint false, idempotentHint false, destructiveHint false), the description adds no behavioral context. It does not disclose that the operation relocates a note, what side effects occur, whether folder associations change, or any permission implications. There is no contradiction with the annotations, but no value is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity is not conciseness when the sentence carries no behavioral meaning. It is boilerplate provenance rather than useful specification, and it does not earn its place in front of the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation-like operation with no schema descriptions and no usage guidance, the description is severely incomplete. An agent cannot tell what the tool does, how to obtain valid IDs, what the return value means, or how it differs from sibling note tools. This is far below minimum viable completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions neither note_id nor folder_id. The parameter names are somewhat self-explanatory, but the description does not explain identities, formats, required lookups, or how they relate to notes_list_folders/notes_list_notes. Low schema coverage means the description needed to compensate, and it did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it only says the tool is a delegated Apple tool named notes_move_note exposed through Apple-Tools-M-CP. It never states that the tool moves a note to a folder, so an agent must rely on the title and parameter names. This does not clear the bar for even a vague purpose statement.
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 about when to use this tool or when to prefer sibling tools such as notes_update_note, notes_create_note, or mail_move_message. The description provides no usage context, alternatives, or exclusions, so the agent is left with no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, so the operation is known to be safe and repeatable. However, the description adds no behavioral context whatsoever, such as search scope, matching behavior, result ordering, or how folder_id/account_name affect the search. It is not contradictory, but it contributes nothing 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short, but it is filler: it restates the tool name and describes transport/delegation rather than functionality. It is under-specification rather than meaningful conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A search tool with five parameters, including scoping filters and pagination controls, gets no usable context. Even though an output schema exists, the agent cannot know what query semantics, folder/account filtering, or paging behavior are expected. The description is far below the minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description names none of the five parameters. The agent is left to guess the meaning of query, limit, offset, folder_id, and account_name from their names alone, with no help from prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only says the tool is 'Delegated Apple domain tool ... exposed through Apple-Tools-MCP,' which is a provenance statement, not a purpose statement. It restates the tool name and provides no verb, resource, or behavior, and it does nothing to distinguish notes_search_notes from notes_list_notes or notes_get_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 search tool versus sibling tools like notes_list_notes, notes_get_note, or notes_list_folders. No context, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond the annotations. It does not disclose whether updates are partial or full replacement, what fields are affected, whether the operation requires permissions, or what happens to unspecified fields. With no such context and only boilerplate text, the description fails to carry its share of transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but this is under-specification rather than conciseness. The single sentence contains only boilerplate about the tool being delegated and exposed, which does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with five parameters, one required, and no usage or behavioral guidance, the description is completely inadequate. Even with an output schema present, the agent has no way to know what updating a note entails or how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no explanation of note_id, title, body_html, folder_id, or tags. The description must compensate for the missing schema documentation but does not mention any parameter semantics at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name: 'Delegated Apple domain tool notes_update_note exposed through Apple-Tools-MCP.' It gives no verb, resource semantics, or differentiation from sibling tools like notes_create_note, notes_append_to_note, or notes_move_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?
There is no guidance on when to use this tool versus alternatives. The title implies updating a note, but the description does not state what scenarios call for it or which sibling tools should be considered instead.
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 declare readOnlyHint and idempotentHint, so the safety profile is already covered. However, the description itself contributes no behavioral information at all, such as whether the tool returns shortcut details, requires specific permissions, or has any special limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity here reflects under-specification rather than conciseness. The single sentence earns no value because it merely wraps the tool name in a generic 'delegated Apple domain tool' statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has one parameter and an output schema, the description provides no functional context. An agent cannot determine what the tool does, what input to supply, or how it differs from neighboring shortcut tools, so the definition is functionally incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must clarify what shortcut_name_or_identifier means and what formats are accepted. The description does not mention the parameter or provide any examples, leaving the agent to guess whether a display name, UUID, or other identifier is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delegated Apple domain tool shortcuts_view_shortcut exposed through Apple-Tools-MCP' merely restates the tool name and adds generic framework context. It does not state that this tool views a shortcut or what viewing entails, so an agent cannot determine the tool's actual function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of siblings like shortcuts_list_shortcuts, shortcuts_run_shortcut, or apple_route_or_run_shortcut. The description provides no selection criteria or context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations carry only openWorldHint/false, idempotentHint/false, and destructiveHint/false, with no readOnlyHint. The description adds no behavioral context: it does not say whether the action is a read or mutation, whether it requires accessibility permissions, whether it affects the frontmost application, or what side effects selecting a popup value may have. It also does not clarify how the tool interacts with the system GUI.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is short because it is vacuous, not because it is efficiently informative. It spends its only sentence on a generic 'delegated ... exposed through MCP' wrapper that could apply to any tool, adding no value while taking up space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a GUI automation tool with five parameters and meaningful behavioral nuances, the description is severely incomplete. Even though an output schema exists, the description fails to explain what popup selection means, how the required 'label' and 'value' parameters are resolved, what permissions are needed, or how this compares to related system_gui_* tools. The agent is not equipped to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsability to explain the five parameters. It explains none of them: label, value, bundle_id, application, and description are undocumented beyond their schema names and types. The relationship between label and value, and when the nullable fields are needed, is left entirely to guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Delegated Apple domain tool system_gui_choose_popup_value exposed through Apple-Tools-MCP,' which simply restates the tool name in a wrapper phrase. It does not state the action, resource, or that this tool selects a value from a system GUI popup. There is no differentiation from sibling GUI tools such as system_gui_click_button or system_gui_type_text.
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 usage guidance whatsoever. It does not mention when to use this tool, when not to use it, or how it compares to sibling GUI automation tools. An agent must infer everything from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavior beyond the tool name. Annotations provide only openWorldHint, idempotentHint, and destructiveHint, none of which are explained; there is no note about read-only semantics, returned data, side effects, or permissions. This falls far short of what a delegated system tool should disclose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it wastes its only sentence echoing the tool name and the generic 'Apple-Tools-MCP' wrapper. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description gives no operational context, no input explanation, no example, and no relationship to the broader preference-reading toolset. An agent would have to guess the meaning of the domain parameter and the function of current_host.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description names neither parameter. 'domain' and 'current_host' are left completely unexplained, with no indication of what values are expected or how current_host modifies behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('system_read_preference_domain') without explaining what reading a preference domain actually does or what kind of resource it operates on. 'Delegated Apple domain tool' adds no functional meaning and fails to distinguish this from related preference tools like apple_get_preferences or system_list_settings_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, what problem it solves, or when to prefer a sibling tool. The description provides zero context about selection among the many preference-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond what annotations already state. It does not disclose whether the change applies immediately, what side effects occur, or what permissions are required. Annotations include destructiveHint=false and idempotentHint=false, but the description contributes nothing additional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than genuinely concise. The single sentence restates the tool name and platform, providing almost no useful information while still occupying the available description space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has only one parameter and an output schema, the description is far too thin to support correct selection or invocation. It omits mode value semantics, behavioral effects, and any relationship to the many sibling system configuration tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'mode', has 0% schema description coverage and the description does not mention it at all. An agent cannot determine valid values (e.g., light/dark) or the expected format, so invocation would be speculative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name in quotes and notes it is 'exposed through Apple-Tools-MCP'; it does not state what setting the appearance mode actually does. The name implies a setter operation, but the description itself provides no verb+resource explanation or differentiation from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 related siblings like system_get_appearance_settings or apple_update_system_setting. No context, preconditions, or exclusions are provided, leaving the agent to guess the appropriate calling scenario.
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 safety profile is covered. However, the description adds no behavioral context beyond those annotations, such as what happens when an event ID is invalid or whether delegation-specific authorization is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not meaningfully concise; it spends its single sentence on wrapper boilerplate rather than functional content. This is under-specification rather than economical writing.
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?
Although this is a simple one-parameter read-only tool with an output schema, the description is missing the core statement of what the tool does. It leaves the agent to infer the entire purpose from the tool name and parameter name, which is inadequate even for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining event_id, its format, or how to obtain a valid value. The only available meaning comes from the parameter name and title, which is insufficient for a low-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and wrapping context: "Delegated Apple domain tool 'calendar_get_event' exposed through Apple-Tools-MCP." It never states that the tool retrieves a calendar event, so it is essentially a tautology with no functional meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 calendar_list_events or calendar_get_event. The description provides no context about when to select this tool, what prerequisites exist, or when another tool would be more appropriate.
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 and idempotentHint, so the read-only behavior is covered there. However, the description adds no additional behavioral context such as return value behavior, attachments, or failure modes; it contributes nothing beyond what the annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the brevity comes from under-specification rather than efficient communication. The sentence merely repeats the tool name and adds a platform wrapper detail that does not help an agent understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and has an output schema, the description provides no functional context. An agent cannot tell that this retrieves a single mail message by ID, what identifier schema is used, or how it compares to mail_get_thread. The wrapper phrase is noise rather than useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify what message_id means, what format it expects, or how it relates to mail threads. The single required parameter is left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and notes it is 'exposed through Apple-Tools-MCP'; it does not state what the tool does with a verb and resource. It offers no differentiation from similar siblings like mail_get_thread or messages_get_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 or how it differs from alternatives such as mail_search_messages, mail_get_thread, or messages_get_message. An agent would have to infer usage entirely from the name.
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 annotations declare readOnlyHint and idempotentHint, but the description adds no behavioral context beyond saying it is 'delegated' and 'exposed through Apple-Tools-MCP.' It does not explain what the operation does, what it returns, or any constraints, so it adds no 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. The single sentence only restates the tool's name and provenance, and it does not earn its place because it conveys no substantive information about the tool's behavior.
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?
Although the tool has a simple signature and an output schema exists, the description fails to state even the basic purpose of the tool. Sibling tools show clear related operations, but without a description of what notes_get_note does, the definition is incomplete for an agent deciding whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the note_id parameter. The parameter name hints it is a note identifier, but the description provides no additional meaning, format, or usage details. With zero schema coverage, this is a major gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it restates the tool name ('notes_get_note') and notes that it is a 'Delegated Apple domain tool' exposed through MCP. It never states what the tool does—such as retrieving a note by ID—so an agent cannot learn its function from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 notes_list_notes or notes_search_notes. The description provides no context, prerequisites, or exclusions to help an agent choose it appropriately.
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 and idempotentHint, so the safety profile is clear. The description adds no behavioral traits, no mention of what menu source is read, and no context about how the listing behaves; it is neutral but empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but earns no place because it merely repeats the tool name. This is under-specification rather than useful conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with an output schema, the missing return format is less critical, but the absence of purpose and parameter semantics leaves an agent unable to decide when to invoke it or what the two identifiers control. The description is incomplete, though not dangerously misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain how bundle_id and application are used or which one to supply. Since the schema provides no parameter descriptions, the tool description should compensate, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name ('Delegated Apple domain tool system_gui_list_menu_bar_items exposed through Apple-Tools-MCP') without a verb or resource. It provides no functional statement beyond what the title already conveys, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No mention of when to use this tool or when to prefer sibling GUI tools like system_gui_click_menu_path or system_gui_type_text. There are no use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, which convey safety and repeatability, but the description itself adds no behavioral context. It does not mention that this lists events, how results are scoped by time range, or any behavior beyond the tool name. No contradiction exists, but the description provides zero 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. A single sentence that only restates the tool name earns its place poorly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two required parameters, an optional calendar filter, and a limit, the tool needs at least a basic explanation of what it does and what inputs mean. The description is so sparse that an agent cannot determine the tool's purpose, invocation context, or result semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates for none of it. The required start_iso/end_iso parameters, optional calendar_id, and limit are entirely unexplained, leaving an agent without any semantic understanding of the arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a pure tautology: 'Delegated Apple domain tool calendar_list_events exposed through Apple-Tools-MCP' merely restates the tool name and says it is exposed through MCP. It states no verb, resource, or action, and does nothing to distinguish this tool from calendar_list_calendars or calendar_get_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as calendar_list_calendars or calendar_get_event. The phrase 'Delegated Apple domain tool' offers no actionable context about prerequisites, scope, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. However, the description adds no behavioral context beyond that: no mention of return behavior, error cases, permissions, or what 'get' entails. It contributes zero transparency beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not meaningfully concise; it is boilerplate that restates the tool name. It does not front-load actionable information, and the single sentence does not earn its place because it adds no operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with an output schema, a complete description could be very brief, e.g., 'Retrieves a contact by its contact_id.' This description provides none of that essential context, making it inadequate for an agent to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no meaning for the sole required parameter, contact_id. The agent gets no help understanding what format or semantics contact_id should have, leaving the schema title 'Contact Id' as the only information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name ('contacts_get_contact') and adds boilerplate about being exposed through Apple-Tools-MCP. It never states what the tool actually does, such as retrieving a contact by ID, and offers no differentiation from sibling tools like contacts_list_contacts or contacts_search_contacts.
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 usage guidance at all. The description does not say when to use this tool instead of contacts_list_contacts, contacts_search_contacts, or other contact-related tools. The need for a contact_id is only implied by the schema, not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. It does not explain whether missing optional fields are cleared or preserved, whether the update is partial or full replacement, what permissions are needed, or what side effects might occur. Annotations include destructiveHint:false, but the description contributes no context of its own.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but its single sentence is essentially a wrapper that restates the tool name plus a generic 'exposed through Apple-Tools-MCP' phrase. It does not earn its place because it communicates no actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a seven-parameter update tool, the description is critically incomplete. It fails to explain update semantics, required identifier behavior, optional field handling, or how this differs from related contact operations. An agent has no basis to call it correctly beyond guessing from the schema and name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the seven parameters. It does not clarify relationships like contact_id being the lookup key, the meaning of empty-string defaults, or how emails/phones are replaced. The schema alone must carry all semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name: 'Delegated Apple domain tool 'contacts_update_contact' exposed through Apple-Tools-MCP.' It does not state that the tool updates contact fields or what kind of updates it performs. Aside from the name/title, there is no meaningful verb-resource specification.
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 about when to use this tool relative to siblings like contacts_create_contact, contacts_delete_contact, contacts_get_contact, or contacts_resolve_message_recipient. The description provides no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, which already cover the safety profile. The description adds no behavioral context beyond that—it does not clarify what listing a directory entails, whether it is recursive, what paths it accepts, or any side effects. There is no contradiction with annotations, but also no added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but this is under-specification rather than effective conciseness. It contains no functional information and earns none of its sentence, failing to front-load any useful meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having output schema and read-only/idempotent annotations, the core behavior is entirely missing. An agent cannot know what this tool returns, what paths are valid, or how it differs from the many other files_* tools in the sibling list. The description is inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. The single 'path' parameter is left undefined beyond its type and title; the description gives no indication whether it must be a directory path, a file path, an absolute path, or a relative path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name ('files_list_directory') and says it is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP. It never states that the tool lists the contents of a directory or what resource it operates on, making it essentially a tautology.
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 about when to use this tool versus siblings like files_search_files, files_get_file_info, or files_list_recent_locations. The description provides no context, prerequisites, or exclusions, leaving the agent without any basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (openWorldHint=false, idempotentHint=false, destructiveHint=false), the description adds no behavioral context whatsoever. It does not disclose what opening means, whether a default app is launched, whether permissions are needed, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than useful conciseness. The single sentence mostly repeats the tool name and adds no operational value.
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 one parameter and an output schema the tool is simple, but even so the description leaves core semantics unstated: what file path it opens, in what app, and with what constraints. Sibling tools show a file-location context, but the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the single required 'path' parameter, its format, absolute/relative requirement, or allowed file types. This is a clear gap since the schema provides only a bare string field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name ('files_open_path') and says it is 'delegated' and 'exposed through Apple-Tools-MCP'; it does not state a verb-action like 'opens the file at the given path in the default application' nor distinguish it from apple_open_file_path/files_reveal_in_finder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use files_open_path versus any alternative such as files_reveal_in_finder, system_open_application, or apple_open_file_path. No prerequisites, exclusions, or selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It does not disclose whether the tool is read-only, whether it requires special permissions, how results are ordered, what counts as 'recent', or what the output contains. The agent is left entirely to the name and the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. It contains only boilerplate framing that could apply to any delegated Apple tool, so the brevity does not serve the agent's decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has an output schema and a single optional parameter, the description is too hollow to support reliable selection or invocation. It does not explain what recent files means, how limit affects behavior, or how this tool differs from the many file-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for this gap. The single parameter 'limit' is left completely unexplained: no meaning, units, bounds, or behavior when omitted. The description adds no value beyond the schema's 'Limit' title and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name in a wrapper phrase ('Delegated Apple domain tool ... exposed through Apple-Tools-MCP') without stating what the tool does. The only real signal is the name itself, which implies listing recent files but is never explicitly confirmed.
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 closely related siblings such as files_list_directory, files_search_files, files_list_recent_locations, or files_get_file_info. No usage context, exclusions, or alternatives are provided.
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 exist and include destructiveHint false, idempotentHint false, and openWorldHint false, so there is no contradiction. However, the description adds no behavioral context, such as whether setting tags overwrites existing tags, requires permissions, or affects files in any unexpected way.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not usefully concise; it consists of boilerplate provenance text that repeats the tool name. It is under-specified rather than efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple two-parameter schema and the presence of an output schema, the description omits the core purpose and any selection guidance. With sibling tools files_add_tags and files_remove_tags present, an agent cannot confidently determine when to call files_set_tags.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters, path and tags, but schema description coverage is 0%. The description provides no guidance on what path refers to, what format tags should take, or whether tags are added or replaced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description never states what the tool does; it only says it is a 'Delegated Apple domain tool' and repeats the tool name 'files_set_tags.' It gives no verb or resource, and does not distinguish it from sibling tools like files_add_tags or files_remove_tags.
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. It does not mention that files_add_tags or files_remove_tags exist, nor whether 'set' replaces existing tags. It is not misleading, but it is completely silent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already show destructiveHint=true and idempotentHint=false, but the description adds zero behavioral context beyond that. It does not mention permanence, confirmation prompts, permission requirements, or any side effects of deleting a message.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It adds no information beyond what the tool name already conveys, so the brevity is not earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with a single required parameter and no usage details, this description is severely incomplete. It lacks any explanation of what the deletion affects, how to obtain message_id, what the output contains, or what safeguards or permissions apply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no meaning for the single 'message_id' parameter. The agent can only guess that it identifies the message to delete; there is no guidance on format, source of the ID, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name ('mail_delete_message') and labels it as a delegated Apple domain tool exposed through Apple-Tools-MCP. It never explicitly states that it deletes a mail message or what resource it acts on, so the agent must infer the entire purpose from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of siblings like mail_move_message, mail_archive_message, or mail_mark_message. No context, no exclusions, and no scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. It does not disclose side effects, reply behavior, account selection, thread targeting, or any permission requirements. Since annotations only provide limited hints, the description fails to carry the burden of behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than conciseness. It repeats the tool name and provides no actionable content, so the single sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema and a list of sibling tools, the description is completely inadequate. An agent cannot determine what the tool does, when to invoke it, or how to interpret its parameters, making the definition insufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of message_id, body, limit, reply_all, or from_account. An agent must infer the meaning of all five parameters from their names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and adds the generic phrase 'Delegated Apple domain tool'. It does not state that the tool replies to the latest message in a thread or describe the action it performs, so an agent cannot determine purpose from the description beyond what the name already implies.
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 such as mail_reply_message or mail_compose_draft. The description provides no context about the intended scenario, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals no behavioral traits beyond the sparse annotations. It does not state that replying typically sends a message, whether accounts must be authorized, whether the operation is reversible, or what side effects occur. With annotations carrying minimal information, the description fails to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified; the single sentence merely names the tool and its exposure mechanism. It does not earn its place because it adds no functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mail operation with four parameters, no usage guidance, no behavioral disclosure, and no parameter explanation, the description is far from sufficient. The agent would need to guess how reply_all and from_account interact and what the output represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters like message_id, body, reply_all, and from_account. It does none of this, leaving the agent to infer semantics solely from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Delegated Apple domain tool ... exposed through Apple-Tools-MCP,' which restates the tool name and provides no verb or resource describing what the tool actually does. The title 'Mail Reply Message' carries the only semantic hint, but the description itself is essentially tautological.
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 mail_reply_latest_in_thread, mail_forward_message, or mail_compose_draft. The description is context-free and provides no exclusions or selection criteria.
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 readOnlyHint and idempotentHint annotations already declare the safe, non-mutating behavior. The description adds no substantive behavioral detail beyond the generic 'Delegated Apple domain tool' phrase, so it contributes little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but the single sentence is filler: it repeats the tool identifier and adds a generic wrapper label. It does not front-load any actionable behavior and fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter search tool with 0% schema description coverage and many mail-related sibling tools, the description leaves out all usage and selection details. The output schema and annotations help, but the description itself is far too sparse for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the four parameters. It does not explain query syntax, limit semantics, mailbox format, or unread_only behavior; parameter names and defaults alone are insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name ('mail_search_messages') and labels it a 'Delegated Apple domain tool', without saying that it searches mail, what results it returns, or how it differs from mail-related siblings. This is essentially a tautology of the name/title.
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 instead of mail_list_mailboxes, mail_get_message, mail_get_thread, or messages_search_messages. No context is given about query construction, mailbox scoping, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide some safety context (openWorldHint true, idempotentHint false, destructiveHint false), but the description adds no behavioral information beyond that. It does not disclose side effects, permissions, conversation-scoping behavior, or what happens on reply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but only because it is nearly empty of content, not because it is economically structured. It does not front-load any useful behavioral or semantic information, so the single sentence fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and siblings that hint at messaging actions, the description is inadequate for an agent to know how to invoke this tool correctly. Critical context is missing: what a conversation is, what format chat_id uses, whether this is a reply versus a new message, and when to choose it over messages_send_message.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to chat_id or text. The schema only gives types and titles, so an agent has no guidance on what chat_id should contain, what text should be, or how they relate to replying in a conversation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only states that the tool is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP, which restates the tool's name and provenance without describing what the tool does. No verb, resource, or action is specified, so an agent cannot determine that this replies to an existing conversation.
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 messages_send_message, mail_reply_message, or messages_get_conversation. There is no context, no exclusions, and no indicated preference among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral disclosure at all. It does not state that this sends a message with an attachment, that it has side effects, that it is non-idempotent, or that Messages permissions may be required. The annotations provide some hints, but the description adds nothing beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not concise in a useful way; it spends its one sentence on provenance rather than behavior. It is under-specified rather than efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a side-effecting tool with three parameters and a 0% schema description coverage, this description is completely inadequate. The presence of an output schema does not compensate for the total absence of functional, usage, or prerequisite information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain recipient, file_path, and text semantics, but it mentions none of them. An agent must guess that file_path is a local file path, recipient is a contact or conversation, and text is optional accompanying content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name and its exposure mechanism ('Delegated Apple domain tool ... exposed through Apple-Tools-MCP'), with no verb describing what the tool does. It reads as a tautology and provides no functional meaning beyond the name itself.
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 usage guidance is provided. The description does not say when to use this tool instead of related siblings like messages_send_message, messages_reply_in_conversation, or messages_list_attachments. The only usage context is implied by the schema and name, not by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral disclosure beyond the annotations. It does not mention that this creates a folder, whether it affects an account, whether folder names must be unique, or what permissions are needed. Annotations exist but add no context for this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity is not useful when it omits all substantive information. The sentence merely identifies the tool by name and wrapper, which does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a mutating Notes operation, two required parameters, and one optional parent-folder parameter, this description is far too incomplete. It provides no operational context, no mention of account targeting, no hierarchical folder semantics, and no guidance on output. An agent cannot confidently call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters. Folder_namme, account_name, and parent_folder_id are left entirely undocumented beyond their names and types, so the agent cannot determine valid values or meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and says it is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP. It never states the actual operation of creating a folder in Notes, making it a tautology rather than a functional explanation.
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 related siblings like notes_create_note or notes_rename_folder. No usage context, prerequisites, or exclusions are provided.
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 annotations declare readOnlyHint=true and idempotentHint=true, which already cover the read-only and idempotent safety profile. However, the description adds no behavioral information beyond those annotations, such as the type of attachment data returned, ordering, or filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but its single sentence is filler that restates the tool name rather than conveying useful information. This is under-specification, not effective conciseness, because the sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that lists attachments, the description lacks even a basic statement of what it returns or what note_id identifies. The presence of an output schema does not compensate for the complete absence of behavioral and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter, note_id, with no schema description, and schema description coverage is 0%. The description does not explain what note_id refers to, how to obtain it, or what format it should take, so the parameter's meaning is entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Delegated Apple domain tool 'notes_list_attachments' exposed through Apple-Tools-MCP,' which restates the tool name and adds no verb, resource, or function. It does not state that the tool lists attachments for a note or how it differs from any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as notes_get_note, notes_search_notes, or messages_list_attachments. The description provides no context for appropriate invocation scenarios.
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 readOnlyHint=true and idempotentHint=true annotations already declare the safety profile, so the description's burden is to add behavioral context beyond that. It adds nothing: no mention of pagination behavior, result ordering, failure modes, or that folder_id/account_name scope the result set. It does not contradict the annotations, but it contributes no transparency value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification, not conciseness. The single sentence does not earn its place because it merely restates the tool name; nothing is front-loaded because there is no actual content to front-load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with 0% schema description coverage, the description is completely inadequate. Even though an output schema exists and read-only annotations are present, the core purpose, parameter semantics, and differentiation from overlapping siblings (notes_search_notes, notes_get_note) are entirely unaddressed, leaving an agent unable to invoke the tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining the four parameters (limit, offset, folder_id, account_name) — and it says nothing about any of them. The unusual anyOf integer|string typing for limit and offset is left completely unexplained, and even the scoping relationship between folder_id and account_name is unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Delegated Apple domain tool notes_list_notes exposed through Apple-Tools-MCP,' is a pure tautology: it restates the tool name and describes platform plumbing ('delegated', 'exposed through Apple-Tools-MCP') without ever stating the verb and resource. An agent must infer the 'list notes' function entirely from the tool's name, which the description fails to confirm.
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 siblings like notes_search_notes, notes_get_note, notes_list_folders, or notes_list_accounts. No context is given for filtering by folder_id or account_name, and no exclusions or alternatives are mentioned. The description provides zero decision support for tool selection.
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 annotations provide some basic hints, but the description adds no behavioral information such as side effects, state changes, or whether completion state is being modified. Without the tool name, there is no indication of what this tool actually does to a reminder.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not genuinely concise because it spends its only sentence on a generic delegation statement with no useful content. It is under-specified rather than efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the schema is simple, the definition fails to state the tool's core function, expected inputs, or relationship to sibling reminder commands. An agent cannot confidently decide when to use this tool or what it will do from the provided description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, reminder_id, with zero description coverage. The description does not explain what this identifier refers to, how it should be formatted, or what the tool does with it, so the agent receives no semantic value beyond the bare schema field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only states that this is a delegated Apple domain tool exposed through Apple-Tools-MCP, which essentially restates the tool name and transport. It gives no verb, resource, or outcome, and does not distinguish it from reminders_complete_reminder or reminders_update_reminder.
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 about when to use this tool rather than the sibling reminder tools. No context, prerequisites, exclusions, or alternatives are mentioned, leaving an agent to infer the intended behavior solely from the name.
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 safety profile is covered. However, the description adds no behavioral context beyond the name: it does not explain what shortcuts are listed, what the optional folder_name does, or what the returned structure represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. The single sentence is essentially a wrapper around the tool name and adds no informative value, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool is simple with one optional parameter and has an output schema, the description leaves the agent without any semantic grounding. An agent cannot determine what the tool lists, how folder_name affects behavior, or how this differs from several sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional folder_name parameter with 0% description coverage, and the description does not compensate. Nothing explains whether folder_name filters results, matches a specific folder, or affects output in any way.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'Delegated Apple domain tool shortcuts_list_shortcuts exposed through Apple-Tools-MCP' merely restates the tool name and platform without saying what the tool actually does. It does not state a verb, resource, or action beyond the name itself.
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 about when to use this tool versus siblings like shortcuts_list_folders, shortcuts_view_shortcut, shortcuts_run_shortcut, or apple_list_shortcuts_for_capability. The description provides no context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It does not mention accessibility permissions, whether the click targets the frontmost app, whether side effects can occur, or whether the click is reversible. It is not contradictory, but it offers no useful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but it spends its space on provenance boilerplate rather than functional information. This is under-specification, not effective conciseness, because the sentence does not help an agent select or invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five optional parameters, zero parameter descriptions, and an output schema, the one-sentence wrapper is completely inadequate. The name alone hints at the action, but there is insufficient context about valid parameter combinations, expected behavior, or return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters: index, label, bundle_id, application, and description. An agent cannot tell how to identify the target button or which parameters are mutually exclusive, preferred, or required in practice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only states that the tool is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP and quotes the tool name. It never says that the tool clicks a GUI button or what the action accomplishes, so the description is essentially a tautology.
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 about when to use this tool versus siblings like system_gui_click_menu_path, system_gui_press_keys, or system_gui_type_text. The description provides no context on prerequisites, target application behavior, or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. It does not explain that this modifies a system setting, whether the change is immediately visible, requires permissions, or affects other Dock settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. It contains only a generic wrapper statement and no useful semantic content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has only one parameter and an output schema, the description is functionally empty. It does not state the tool's purpose, effect, or when it should be called, leaving the agent to guess from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the meaning of the required boolean 'enabled'. An agent cannot tell from the description whether true means autohide is turned on or off.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and wraps it in a generic 'Delegated Apple domain tool' phrase. It does not actually say that the tool enables or disables Dock auto-hide, so it fails to provide a specific verb and resource beyond the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the many sibling system_set_* tools, such as system_set_dock_show_recents. An agent receives no context about appropriate conditions, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits whatsoever. The annotations only carry openWorldHint, idempotentHint, and destructiveHint — there is no readOnlyHint — yet the description never says whether this mutates persistent system state, whether it requires permissions, or what the side effects of enabling/disabling are. It adds no context beyond what the annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than conciseness. The single sentence is a boilerplate delegation notice that could apply verbatim to any Apple-domain tool; it does not earn its place and could easily be replaced with a same-length functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter system-setting setter, an agent needs at minimum to know what Dock behavior 'show recents' refers to and what true/false does. Even with an output schema present, the description is a generic delegation notice with no behavioral, parameter, or selection context, so it is entirely inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single required boolean 'enabled', but it says nothing about what 'enabled' means, its default, or its effect on the Dock. The parameter title 'Enabeled' and the tool name are the only hints; the description itself adds no meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a provenance statement — 'Delegated Apple domain tool ... exposed through Apple-Tools-MCP' — not a functional one. It never states what the tool does; the verb 'set' and resource 'dock show recents' live only in the tool name, and the description offers no clarification of the effect. Among many system_set_* siblings, it provides no differentiation.
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 usage guidance at all: no when-to-use, no when-not-to-use, no mention of alternatives or prerequisites. An agent choosing between system_set_dock_show_recents, system_set_dock_autohide, and the other system_set_* tools receives zero help from this 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 annotations already include destructiveHint=true, but the description adds nothing about what deletion means, whether the operation is reversible, what permission implications exist, or what types of paths are valid. It neither contradicts the annotations nor contributes behavioral detail beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entry is short, but the brevity is under-specification, not efficient writing. The single sentence spends its effort on provenance ('Delegated... exposed...') rather than on the operation the agent must understand to invoke the tool safely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool, the description should state what is deleted, scope, and any relevant caveats. The output schema and annotations cover return shape and destructiveness, but the description itself provides almost no semantic completeness; the agent is left to infer nearly everything from the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain what the 'path' parameter refers to and any expected format or constraints. It does not, so the agent must rely entirely on the bare parameter name 'Path' and the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is purely a wrapper: 'Delegated Apple domain tool 'files_delete_path' exposed through Apple-Tools-MCP.' It restates the tool name and platform without stating what the tool actually does, delivering no verb-resource semantics beyond the name itself.
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 files_move_path, files_open_path, or files_reveal_in_finder. The description is not actively misleading, but it provides no situational context, exclusions, or alternative routing.
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, covering the safety profile. However, the description adds no behavioral context beyond that — it does not mention what is returned, whether a file must exist, or any edge cases. The 'Delegated Apple domain tool' boilerplate adds no operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than conciseness. The single sentence is boilerplate filler that repeats the tool name and adds no useful information, so it earns no credit for efficient packing of meaning.
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?
Although the tool is structurally simple — one required path parameter and an output schema — the description still fails to state the core operation or clarify parameter expectations. An agent would have to rely entirely on the tool name and sibling-tool context to guess that this reads tags from a file path, which is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the path parameter. It does not mention 'path' at all, its format, whether it expects a POSIX path, or how the tool interprets it. The agent receives no semantic guidance beyond the parameter name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name ('files_get_tags') and says it is 'exposed through Apple-Tools-MCP' — it never states the actual operation of getting tags for a file. This is essentially a tautology with no verb or resource action, so an agent cannot learn the tool's purpose from the description.
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 such as files_set_tags, files_add_tags, or files_remove_tags. The description provides no context, exclusions, or alternatives, leaving the agent to infer usage entirely from the tool name.
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 and idempotentHint, so the operation's safety profile is known. However, the description itself contributes no behavioral context—no mention of scope, limitations, or what 'recent locations' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity is not conciseness when the only sentence is a restatement of the tool name. It contains no useful information that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description still fails to explain what the tool returns, what a 'recent location' is, or how 'limit' affects behavior. The provided context is insufficient for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the one parameter 'limit' is left entirely unexplained. Since the description must compensate for the missing schema documentation and does not, the agent gets no semantic help for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it repeats the tool name and states it is an 'Apple domain tool' without defining what the tool actually does. There is no verb, no resource, and no distinction from siblings like files_recent_files.
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 files_recent_files, files_list_directory, or files_search_files. It does not mislead, but it also gives the agent nothing to select on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint and idempotentHint, but the description adds zero behavioral context. It does not say what health checks are performed, what state is inspected, or what the result represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity is not value here. The only sentence is essentially a restatement of the tool name and its transport, so it under-specifies rather than informing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has no parameters and annotations cover safety, the description fails to state the tool's basic purpose or expected output. An agent cannot reasonably decide when or why to invoke it.
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 no parameters, so the description is not required to explain parameter meaning. The baseline of 4 applies because there is nothing for the description to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name and says it is exposed through Apple-Tools-MCP. It provides no verb, resource, or functional outcome, so an agent cannot determine that this is a health/diagnostics tool for the mail domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool, what problem it solves, or how it differs from sibling health tools like apple_health, calendar_health, or reminders_health. The agent is left without any selection criteria.
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 and idempotentHint, so the agent knows it is safe and idempotent. However, the description adds no behavioral context beyond that, such as what mailboxes are returned, whether the account parameter is required, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the brevity comes from omitting substantive content rather than from efficient explanation. It spends its one sentence on a meta-wrapper phrase instead of describing the operation.
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?
Even though the tool is simple and has an output schema, the description still fails to explain what listing mailboxes means, what the account parameter controls, or what the agent should expect in the response. In the context of many sibling mail tools, this is not enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional 'account' parameter has no schema description and 0% schema coverage. The tool description also does not explain what 'account' means, what format it should take, or what null/default behavior implies. This leaves the only parameter effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it repeats the tool name and says it is 'exposed through Apple-Tools-MCP', but never states what the tool actually does. There is no verb, resource description, or distinction from sibling mail tools.
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, what scenario it fits, or how it differs from related tools like mail_search_messages or mail_suggest_mailboxes. An agent gets no help selecting it over alternatives.
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 information beyond the annotations. While destructiveHint=false provides some safety context, the description does not disclose what 'mark' modifies, whether it changes read state, requires mail permissions, or has side effects. With an idempotentHint=false, this gap is more significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified boilerplate rather than genuinely concise. It contains no useful operational content, so the brevity does not contribute to agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mail mutation tool with two required parameters and many sibling mail tools, the description is severely incomplete. It does not clarify the marking operation, the meaning of is_read, or how it differs from related mail tools. The output schema exists but cannot compensate for the absence of core semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain message_id and is_read, but it does not mention either parameter. The schema's property names are somewhat self-explanatory, but the description adds zero semantic value and fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only says it is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP, which restates the tool name without defining what the tool actually does. The action 'mark' is only inferable from the tool name and the is_read boolean parameter, not from the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 mail_move_message, mail_archive_thread, or mail_delete_message. No context, prerequisites, or exclusions are provided, leaving the agent to guess how this tool fits into the mail workflow.
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 declare readOnlyHint and idempotentHint, but the description adds no behavioral context beyond those annotations. It does not mention scope, result behavior, filtering, or anything else that would help an agent understand side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but wastes its words on metadata instead of content. It is under-specified rather than usefully concise, and provides no front-loaded operational information.
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?
Even though annotations and an output schema exist, the description is insufficient to tell an agent what queryingredient is expected, what limit controls, or how this differs from the strict sibling. For a search tool, a clear 'search Apple Maps for places matching a query' would be the minimum context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain query and limit semantics but does not mention either parameter. The tool name implies a search, but the description adds no meaning beyond the schema's field names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name and says it is 'Delegated' and 'exposed through Apple-Tools-MCP'. It contains no verb or resource indicating what the tool actually does, so it is essentially tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as apple_maps_search_places_strict, maps_get_directions, or maps_build_maps_link. The agent can only infer usage from the tool name, not from the 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 annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. However, the description adds no behavioral context such as return shape, message scope, or failure behavior; 'Delegated' is a harness detail, not a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not meaningfully concise—it is under-specified. The single sentence repeats the tool name and packaging context instead of explaining behavior or key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema being present, the description lacks even a minimal statement of what the tool does. An agent must infer everything from the tool name and title. For a simple get-by-id tool this is somewhat recoverable, but the definition is not complete enough to support correct invocation in ambiguous contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about message_id. The parameter name and title 'Message Id' imply its role, but the description does not compensate for the missing schema description or clarify format, scope, or expected source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delegated Apple domain tool 'messages_get_message' exposed through Apple-Tools-MCP' merely restated the tool name and framework; it does not state that the tool retrieves a message or what message_id identifies. No specific verb or resource behavior is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 instead of siblings such as messages_get_conversation, messages_search_messages, or maill_get_message. No context, prerequisites, or alternativa conditions are mentioned.
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 annotations already document readOnlyHint and idempotentHint, but the description adds no behavioral information about pagination, ordering, unread filtering, or return behavior. It neither contradicts the annotations nor enriches them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the space is wasted on boilerplate that repeats the tool's name. This is under-specification rather than effective conciseness.
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?
Although the annotations and output schema provide some safety and return-shape context, the description omits the core purpose and any parameter semantics. For a tool that an agent must select among many sibling message tools, this is not complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain limit, offset, or unread_only. An agent has to guess at the meaning of these parameters, especially the string-or-integer union types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool's name and says it is exposed through Apple-Tools-MCP. It never says that the tool lists conversations, so an agent cannot derive the actual function from the description.
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 about when to use this tool versus alternatives like messages_search_messages or messages_get_conversation. The description is not misleading, but it provides zero 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=true and idempotentHint=true, covering the safety proile. The description adds no additional behavioral context — no mention of return values, searche scope, date-range semantics, or pagination. It does not contradict the annotations but contributes nothing beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short, but this is under-specification rather than conciseness. Every word is boilerplate that earns no value, and no functional content is front-loaded or otherwise present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter searche tool with 0% schema coverage, this description is wholly inadequate. Even with an output schema present, the input semantics are completely unexplained, and an agent cannot reliably construct a correct searche call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters, so the description must compensate and fails entirely. It explains neither what 'query' matche against, nor the expected format for start_iso/end_iso, nor how sender and chat_id filters interact. An agent is left guessing about every parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it restates the tool name in quotes and adds only boilerplate about being 'delegated' through Apple-Tools-MCP. It never states that this tool searche messages, what is searche for, or how it differs from nearly idential siblings like mail_searche_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zer guidance on when to use this tool versus alternatives. With mail_searche_messages, messages_list_conversation, and messages_get_message among the siblings, an agent gets no help choosing between them. No context, no exclusions, no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and idempotentHint annotations already communicate the safety profile, and the description adds no behavioral context beyond calling the tool 'delegated'. It does not contradict the annotations, but it also contributes no useful behavior information such as default account scoping, pagination semantics, or whether nested/empty folders are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is short because it is under-specified, not because it is efficiently informative. The sentence spends its words restating the tool name and MCP exposure, neither of which helps an agent invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the output schema and annotations exist, the description is functionally empty for an agent trying to decide when and how to use this tool. It does not explain the folder-listing behavior, optional account filtering, or pagination semantics, so the definition is incomplete for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention limit, offset, or account_name. The agent gets only raw parameter names and defaults from the schema; no semantic meaning is supplied for these parameters in either the description or schema property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it restates the tool name 'notes_list_folders' and says it is exposed through Apple-Tools-MCP, but never states that it lists folders or what listing folders entails. The functional meaning is only inferable from the name/title, not from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like notes_list_accounts, notes_list_notes, or notes_create_folder. The description says nothing about typical use cases, prerequisites, or when another sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations already provided. 'Delegated Apple domain tool' is generic boilerplate and does not disclose what the operation returns, its scope, or any side effects. It does not contradict the readOnlyHint or idempotentHint, but it also contributes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it spends its single sentence restating the tool name and platform instead of explaining functionality. This is under-specification rather than genuinely concise, useful writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: no parameters, read-only, idempotent, and has an output schema. However, the description still fails to state the core purpose, so an agent must rely entirely on the tool name to infer what it does. Minimal but necessary context is missing.
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 already makes this clear with an empty properties object. There is no parameter behavior for the description to explain, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name and says it is 'exposed through Apple-Tools-MCP'; it never states that the tool lists calendars. This is essentially a tautology that provides no verb, resource, or functional meaning beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool, what problem it solves, or how it differs from related sibling tools like calendar_list_events or calendar_health. The agent is given no selection criteria.
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 declare non-destructive behavior, so the safety bar is partially met by structured data. However, the description adds no behavioral context whatsoever — critically, it never states whether 'add' appends tags to existing ones or replaces them, which is the key distinction from files_set_tags. No mention of path format expectations, overwrite behavior, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specification rather than efficient conciseness. The 'Delegated Apple domain tool ... exposed through Apple-Tools-MCP' framing is implementation trivia that doesn't help an agent select or invoke the tool. No substance earns the space it takes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema covers return values, the description is completely inadequate for a tool with closely related siblings (files_set_tags, files_remove_tags, apple_tag_file). It fails to state the core semantic — whether tags are appended or replaced — and gives no hint about path scope or prerequisites. An agent cannot reliably select or invoke this tool correctly from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameter semantics — and it says nothing about path or tags. The parameter names are mildly self-explanatory, but there's no guidance on path format (POSIX vs file://), whether directories are supported, or tag formatting constraints. The description fails to compensate for the 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Delegated Apple domain tool 'files_add_tags' exposed through Apple-Tools-MCP' — it restates the tool name and adds boilerplate about how it's exposed, without stating what the tool does. The verb+resource is absent; an agent must infer from the name and schema that it adds tags to files. This is close to a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Zero guidance on when to use this tool. The sibling list includes files_set_tags, files_remove_tags, files_get_tags, and apple_tag_file, which creates a real selection problem: an agent cannot tell whether to use add vs set vs apple_tag_file. No context, exclusions, or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. It does not state whether the operation renames, overwrites, moves across volumes, preserves metadata, or what happens to the source path after the move. With no readOnlyHint and only sparse annotations, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but empty; this is under-specification rather than effective conciseness. It front-loads boilerplate ('Delegated Apple domain tool') instead of the actual operation. Every sentence should add value, and here neither sentence does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating file operation with no behavioral explanation, the description is inadequate. An agent cannot determine path semantics, error conditions, overwrite behavior, or whether this is the right tool versus the many file-related siblings. The existence of an output schema does not compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description needed to compensate by explaining that source and destination are filesystem paths and what forms they may take. It does not. The parameter names 'source' and 'destination' are somewhat self-explanatory, but no additional semantic detail is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name ('files_move_path') and labels it a 'Delegated Apple domain tool' without explaining what moving a path actually does. There is no verb, resource, or scope beyond what the title already conveys. It is essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus related file tools such as files_delete_path, files_open_path, or files_list_directory. There is no mention of appropriate scenarios, preconditions, or alternatives. An agent receives no decision-relevant context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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, but the description adds zero behavioral context beyond them. It does not contradict the annotations, yet it contributes nothing about return values, scope, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than conciseness. Its single sentence carries no useful information and does not earn its place.
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?
While the tool is simple (0 params, output schema present), the definition still fails to state what is returned or which appearance settings are covered. Given the crowded system_get_* sibling group, this gap is meaningful.
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 leaves nothing undocumented. Per the baseline rule, the description need not explain parameters, and it correctly avoids inventing any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it merely restates the tool name ('system_get_appearance_settings') and adds the wrapper fact 'exposed through Apple-Tools-MCP'. It never states what appearance settings are retrieved (e.g., dark mode, accent color) or what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 siblings such as system_get_accessibility_settings, system_get_settings_snapshot, or system_read_preference_domain. An agent has no basis for selecting among the many system_get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is destructive and non-idempotent, so the description's burden is lower, but it still adds no behavioral context such as irreversibility, permission requirements, or consequences of deleting an event. The description merely repeats the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but its only sentence is boilerplate that does not earn its place. It is under-specified rather than usefully concise, providing no actionable information for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a single-parameter tool with an output schema and destructive annotations, the description fails to state the core operation. An agent cannot reliably know from this description that invoking the tool deletes a calendar event, making the definition fundamentally incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining parameter meaning. It says nothing about event_id, its format, how to obtain it, or any constraints. The self-explanatory parameter name does not compensate for the complete lack of description support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and adds 'Delegated Apple domain tool,' which does not specify what the tool actually does. It fails to explicitly state that it deletes a calendar event, leaving the agent to infer the action from the tool name and title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as calendar_update_event or calendar_get_event. The description is purely boilerplate and gives the agent no decision support for selecting among related calendar tools.
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 tool name and annotations already imply. With annotations like idempotentHint=false and destructiveHint=false present, the description provides no additional detail about partial updates, required ownership, or effects on recurrence, so the agent must infer the mutation semantics from the name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than conciseness. The single sentence spends its words on generic delegation/MCP framing instead of earning its place with functional content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, 0% schema description coverage, and mutation semantics, this is severely incomplete. The description provides no guidance on how to use the tool, what updating an event entails, or how it differs from calendar_create_event and calendar_delete_event.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the 9 parameters. The agent is left without explanation for required event_id, ISO datetime formats, recurrence object shape, or which fields can be updated together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only repeats the tool name ('calendar_update_event') and generic platform framing ('Delegated Apple domain tool ... exposed through Apple-Tools-MCP'). It never states the actual action, resource, or effect, and it does not differentiate from siblings like calendar_create_event, calendar_delete_event, or calendar_get_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. It does not mention that it updates an existing calendar event, nor does it contrast with calendar_create_event for new events or calendar_delete_event for removal.
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 declare destructiveHint=false, but the description adds no behavioral context such as what the tool creates, how it handles duplicates, or any permission requirements. The phrase 'delegated Apple domain tool' discloses nothing about observable behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short but entirely generic, merely identifying the tool as delegated and exposed without adding useful information. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates contacts with six parameters and no usage guidance, the description is far from complete. It lacks even a basic statement of what the tool does, parameter examples, or any context about when it should be invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter information. The agent must rely solely on property names like first_name, emails, and phones, with no explanation of required combinations, value formats, or the meaning of the ContactMethod label/value structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says only that the tool is a 'Delegated Apple domain tool' and quotes the tool name, but it never states what the tool actually does, such as creating a contact. The purpose is inferable only from the tool name and title, not from the description itself.
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 sibling tools like contacts_update_contact, contacts_delete_contact, or apple_prepare_unique_contact. The description does not mislead, but it provides zero context for selecting this tool over alternatives.
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 information beyond the annotations. destructiveHint=true already signals a destructive operation and idempotentHint=false signals non-idempotency, but the description does not add context about what exactly is destroyed, whether deletion is permanent, or what permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but is mostly boilerplate: 'Delegated Apple domain tool... exposed through Apple-Tools-MCP' earns no real value and does not front-load the tool's actual purpose. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive one-parameter tool, the description is not complete enough. The annotations cover the destructive nature and the output schema may cover return values, but the description fails to state the core operation, usage context, or effect on the contact resource.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate, but it says nothing about the contact_id parameter. The parameter name and title make it reasonably clear, but the description provides no extra meaning about the expected format or where the ID comes from.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state that the tool deletes a contact; it only restates the tool name as a 'Delegated Apple domain tool' exposed through a wrapper. The eventual action is inferable from the name and title, but the description itself provides no specific verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of contacts_update_contact, contacts_list_contacts, or contacts_search_contacts. No prerequisites, such as obtaining a valid contact_id, are mentioned.
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 detail such as whether parent directories are created, what happens if the folder already exists, or whether permissions are needed. The annotations provide only non-destructive/idempotency hints, and the description does not supplement them with any real behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity here is under-specification rather than effective conciseness. It front-loads no usable information and spends its only sentence on boilerplate framing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating filesystem operation with one required path parameter, this description is functionally empty. Even with the output schema present, an agent cannot determine basic semantics, error behavior, or expected input format from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the meaning of the required 'path' parameter, but it does not. The agent is told a path is required without any clarification of whether it is a target directory, a parent path, or a full path including the new folder name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only says it is a 'delegated Apple domain tool' exposed through Apple-Tools-MCP, which essentially restates the name without explaining the operation. It never explicitly states that this tool creates a folder at a given path, so a new agent must infer the entire purpose from the name alone.
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 about when to use files_create_folder, what prerequisites exist, or how it differs from sibling file operations like files_move_path or files_list_directory. The agent is left without any decision support for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, but the description adds no behavioral context beyond those annotations. It does not disclose search scope, path restrictions, permission requirements, or any other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but this is under-specification rather than effective conciseness. The only sentence spends its words on the tool name and exposure mechanism instead of earning its place with functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no schema descriptions, and siblings like files_list_allowed_roots that affect path validity, the description leaves critical operational context unspecified. An agent cannot reliably determine what can be searched, under which root, or what constraints apply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining query, limit, and base_path. It mentions none of them, leaving the agent to rely solely on parameter titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('files_search_files') and adds only provenance ('exposed through Apple-Tools-MCP'), so it does not actually state what the tool does. It is a tautology rather than a functional definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus sibling tools like files_list_directory, files_recent_files, or files_list_allowed_roots. There are no exclusions, prerequisites, or alternative-selection conditions.
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 say destructiveHint=false and idempotentHint=false, but the description adds no behavioral context; the word 'archive' in the title implies moving/copying a message thread, but the description itself does not state side effects, permission needs, or what happens to the original messages. The description doesn't contradict the annotations, but it contributes no behavioral transparency beyond what the title suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but uninformative; it spends its only sentence on the unhelpful 'Delegated Apple domain tool' boilerplate rather than explaining what the tool does. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with 0% schema coverage and no meaningful description, the definition is grossly incomplete. Even though an output schema exists, the agent cannot know what inputs mean or what the operation does, and sibling tools such as mail_get_thread and apple_archive_message create ambiguity that the description never resolves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so no parameter is documented in the schema. The description also fails to explain any parameter, including the required message_id, the meaning of limit, archive_account, or archive_mailbox. With 0% schema coverage and no description-based parameter guidance, the agent has almost no semantic information to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The name and title suggest archiving a mail thread, but the description only states it is a 'Delegated Apple domain tool' exposed through a bridge, which doesn't say what the tool does. The verb is absent or at best implicit in the title, and it doesn't distinguish from sibling tools like mail_get_thread, mail_move_message, apple_preview_archive_message, or apple_archive_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus any of the many mail-related siblings. There is no indication of prerequisites, such as needing an archive_account/archive_mailbox, or when to prefer mail_move_message or apple_archive_message instead.
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 declare readOnlyHint and idempotentHint, but the description discloses no behavioral details beyond a generic 'Delegated Apple domain tool' phrase. It adds zero context about what the tool does, what chat_id refers to, or what the response contains. No contradiction, but no value either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
It is short, but it is under-specified rather than concise: one sentence that restates the tool name and adds generic MCP exposure boilerplate. The sentence does not earn its place because it contributes no meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversation-retrieving tool with 3 params and an output schema, the description should at least say it fetches a message conversation. None of that is present. An agent cannot tell what domain it operates on, what data it returns, or how it relates to other messaging tools, leaving the definition essentially empty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description includes no parameter information. chat_id, limit, and offset are only bare names in the schema without explanations, and the description does nothing to compensate for this gap. An agent must guess the meaning of chat_id and pagination parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says it is a 'Delegated Apple domain tool' and restates the tool name, but never states what the tool does. It is essentially a tautology of the name/title and gives no verb or resource.
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 about when to use this tool instead of siblings like messages_get_message, mail_get_thread, or apple_suggest_message_conversations. There is no context, no exclusions, no alternatives.
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 indicate destructiveHint=true and idempotentHint=false, but the description adds no behavioral context beyond that, such as whether messages are actually delivered, permission requirements, or side effects. With annotations present the bar is lower, but the description still contributes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not usefully concise; it is under-specified boilerplate that repeats the tool name. It earns no credit for brevity because it omits substantive information rather than summarizing it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a simple two-parameter signature, the tool performs a meaningful side-effectful action (sending a message) and has a destructive hint. The description fails to explain sender identity, recipient format, delivery behavior, or any prerequisites, leaving the agent unable 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.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of what 'recipient' or 'text' mean in practice, such as expected formats, phone/email resolution, or constraints. This violates the need for the description to compensate when the schema is bare.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool's name and says it is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP; it does not state what sending a message entails. The title 'Messages Send Message' carries the only real meaning, but the description itself adds no functional clarity.
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 messages_reply_in_conversation or messages_send_attachment. The description provides no context for selecting this tool over its siblings.
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 convey idempotentHint=false and destructiveHint=false, but the description adds no behavioral context beyond 'Delegated Apple domain tool.' It does not disclose persistence, permission requirements, duplicate behavior, or side effects, so the description fails to contribute meaningful behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but it is under-specified boilerplate rather than concise useful documentation. The single sentence merely restates the tool name and platform, so it does not earn its place as meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool is simple and has an output schema, the description lacks purpose, usage guidance, parameter semantics, and behavioral context. An agent would need to infer the entire operation from the tool name and sibling list, which is insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'title' parameter, its expected format, constraints, or how it relates to the created list. The description does nothing to compensate for the lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name ('Delegated Apple domain tool 'reminders_create_list''), providing no verb or resource semantics beyond the name/title. It does not explicitly say that the tool creates a Reminders list, so an agent cannot understand the operation from the description alone.
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 about when to use this tool versus sibling tools such as reminders_create_reminder or reminders_list_lists. No context, exclusions, or alternatives are provided, so the agent is left to infer invocation conditions from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, openWorldHint=false, and idempotentHint=false, but the description itself adds no behavioral context. It does not state that deleting a list may cascade to contained reminders, whether deletion is reversible, or any permission requirements. The description contributes nothing beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but not usefully concise — it is under-specified and repeats the tool name. No information is front-loaded because no functional information exists at all.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has a single parameter and an output schema, this is a destructive operation that gives the agent no indication of what it deletes, what the side effects are, or how to identify the target list. The description is far below minimum viable completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter list_id has no description in the schema, and schema description coverage is 0%. The tool description also never explains what list_id should be, where to obtain it, or how it is used. The description fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name — 'reminders_delete_list' — and adds only generic boilerplate about being a delegated Apple domain tool exposed through MCP. It never explicitly says 'deletes a reminder list,' so the agent must infer behavior from the name. This is a tautology rather than a functional explanation.
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 about when to use this tool instead of related siblings such as reminders_delete_reminder, reminders_create_list, or apple_suggest_reminder_lists. The description provides no selection criteria, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true and idempotentHint=true, but the description adds zero behavioral context. It does not explain what a health check does, what it returns, or whether any permissions are needed. The description neither contradicts nor complements 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than effective conciseness. The single sentence is boilerplate and conveys no functional information, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, safe annotations, and no parameters, the description leaves the core meaning undefined. An agent can invoke the tool trivially but cannot determine why or when to do so, making the definition incomplete for practical use.
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 empty schema fully documents invocation. Baseline 4 applies, and no additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name as a 'Delegated Apple domain tool' and appends boilerplate about being exposed through Apple-Tools-MCP. It lacks an action verb or resource description, so an agent cannot determine what 'health' means for reminders or how this differs from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool, what conditions warrant it, or how it relates to alternatives like reminders_list_lists or system_health. No context or exclusion criteria are provided.
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 declare readOnlyHint and idempotentHint, and the description does not contradict them. However, the description adds no behavioral context such as default include_completed=true behavior, filter semantics, or what kind of results are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is uninformative boilerplate that repeats the identifier. It is under-specified rather than genuinely concise, and the single sentence carries no useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the description omits the core action, purpose, and parameter meaning. An agent choosing among a large set of reminder and Apple tools would receive no contextual help from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 6 parameters, and the tool description does not mention limit, search, list_id, due_after, due_before, or include_completed. The description fails entirely to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Delegated Apple domain tool reminders_list_reminders exposed through Apple-Tools-MCP,' merely echoes the tool name and title without stating a verb, resource, or outcome. An agent cannot learn from the description itself that this tool lists reminders.
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 about when to use this tool or how it differs from alternatives like reminders_get_reminder, reminders_list_lists, or reminders_create_reminder. The description provides no selection context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide readOnlyHint=true and idempotentHint=true, but the description adds no behavioral context beyond that. It does not disclose what the tool returns, what 'health' means, whether it contacts external services, or how results should be interpreted. The description carries essentially none of the behavioral disclosure burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence, but it is short because it is empty, not because it is tightly informative. The boilerplate phrase 'Delegated Apple domain tool' does not earn its place—it provides no actionable information to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simplified no-parameter health check, the description must explain what is being checked and what the output represents. It does neither. An agent is left to rely solely on the name and sibling patterns, which is insufficient for confident invocation.
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 there is nothing for the description to clarify. With no parameters to document, the baseline is 4, and the description's silence on this front is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only identifies the tool as a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP, but never states what 'shortcuts_health' actually does. The name implies a health check, but the description does not provide a verb, resource, or functional outcome. It is nearly a tautology that restates the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever about when to use this tool, what conditions call for it, or how it differs from sibling tools like system_health, mail_health, or reminders_health. An agent receives no basis for selecting it over alternatives.
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 indicate idempotentHint=false and destructiveHint=false, but the description adds no behavioral context of its own. It does not mention that running a shortcut may execute arbitrary actions, require permissions, or produce side effects, which is especially important because the tool accepts input text, input paths, and an output path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is empty boilerplate rather than useful conciseness. It front-loads no key behavior and does not earn its place because it merely restates exposure through Apple-Tools-MCP.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, one required argument, optional file inputs/outputs, and an output-type setting, this description is severely incomplete. Even though an output schema exists, the description still fails to explain how to run a shortcut, what the parameters mean, what side effects may occur, or how this relates to the many sibling shortcut tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain shortcut_name_or_identifier, input_text, input_paths, output_path, and output_type, but it does not mention any of them. The prose adds no meaning beyond the parameter names and types already visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and says it is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP; it never explicitly says it runs a shortcut. The agent must infer the purpose from the tool name and title, and no differentiation from siblings like shortcuts_view_shortcut or apple_route_or_run_shortcut is provided.
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 about when to use this tool versus alternatives such as apple_route_or_run_shortcut, apple_suggest_shortcuts, or shortcuts_list_shortcuts. The description gives no context, prerequisites, or exclusions, so the agent has to guess based on sibling names.
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 and idempotentHint, so the safety profile is covered. The description adds no behavioral context beyond calling the tool 'Delegated Apple domain tool', which is boilerplate and does not disclose what happens on invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. Its single sentence contains no useful content and does not earn its place relative to the information already available in the tool name and annotations.
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?
Although the tool is simple, has annotations, and has an output schema, the description is still missing the core semantic statement of what the tool does. A minimal 'Lists contacts with pagination' would be needed for the definition to be complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds nothing about limit or offset. It does not mention pagination, defaults, or how the parameters affect results, so the agent receives no semantic help beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name ('contacts_list_contacts') and says it is 'exposed through Apple-Tools-MCP'; it does not state what the tool does in functional terms. This is essentially a tautology with no verb/resource semantics beyond what the name implies.
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 siblings like contacts_search_contacts or contacts_get_contact. The description provides no context for listing contacts, no mention of pagination behavior, and no exclusions or alternatives.
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 annotations already declare readOnlyHint and idempotentHint, covering the safety profile, but the description adds zero behavioral context beyond that. It does not disclose error behavior for missing or invalid paths, whether the path must be absolute, permission requirements, or what information is returned. There is no contradiction with annotations, but the description itself contributes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but this is under-specification rather than effective conciseness. The single sentence is spent restating the tool name inside generic delegation boilerplate instead of conveying function, behavior, or parameter meaning, so the brevity earns no credit.
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?
An output schema exists and annotations are strong, which lowers the burden, but the description still fails to explain the tool's core purpose, the meaning of the path parameter, or how to choose it among many file-related siblings. With only one required parameter, the missing purpose and parameter semantics leave the definition materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to compensate: the sole parameter 'path' is entirely undefined — no format, no absolute-vs-relative guidance, no file-vs-directory distinction. With no enums and no textual help in either the schema or the description, an agent has no semantic grounding for the one required argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it restates the tool name ('files_get_file_info') and adds only the generic wrapper phrase 'Delegated Apple domain tool... exposed through Apple-Tools-MCP.' It never states what 'file info' actually means, what properties are returned, or how this differs from sibling tools like files_list_directory, files_read_text_file, or files_get_tags. The title carries the only real meaning, not the description.
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 call this tool versus alternatives. There is no mention of when to prefer files_get_file_info over files_list_directory, files_read_text_file, files_get_tags, or files_search_files, and no preconditions, exclusions, or context for selecting it 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?
The annotations declare readOnly and idempotent behavior, so safety is covered, but the description adds no behavioral context beyond that. 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The sentence is short but essentially restates the tool name in prose. It is under-specified rather than meaningfully concise, and it does not earn its place by adding functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and annotations cover return shape and safety, but the description fails to explain what iCloud status is being reported or how to interpret it. An agent would have to rely entirely on the tool name to guess its semantics.
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 description need not explain arguments. The empty schema is complete, and this is the appropriate baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and notes that it is a delegated Apple domain tool. It does not state what iCloud status is being retrieved or offer any meaningful verb/resource semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool or when to prefer related tools such as files_health or files_get_file_info. No alternatives, exclusions, or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 safety profile is known. The description adds no behavioral context beyond the annotations and no useful details about output, permission implications, or scope of 'allowed roots.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than purposeful conciseness. It is boilerplate that says nothing meaningful about the tool's function, so brevity does not earn credit.
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?
Although there are no parameters and an output schema exists, the description omits the core semantic information: what 'allowed roots' are, why an agent would call this tool, and how the result should be interpreted. For a zero-argument tool, that is the main missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is no parameter documentation burden. With no parameters to explain, the description does not need to compensate, and the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and labels it a 'Delegated Apple domain tool'; it does not state a verb, action, or resource. There is no semantic content explaining that the tool lists allowed root paths, and no distinction from other files_ or apple_ siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool, what problem it solves, or when to prefer an alternative. The phrase 'Delegated Apple domain tool' is not actionable usage direction.
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. It does not explain path interpretation, file size limits, encoding, permissions, or what happens when max_bytes is exceeded. Since destructiveHint is false, the agent at least knows this is not destructive, but the description contributes nothing beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and easy to scan, but its single sentence does not earn its place because it only repeats the tool name and adds a generic exposure note. It is under-specified rather than usefully concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and the annotations provide safety hints, the description is incomplete for a file-reading tool. It lacks any statement of what the tool does, how path should be resolved, what max_bytes controls, or what the returned content looks like. An agent could infer much of this from the name and schema, but the description itself is not complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the parameters, but it does not. The schema only provides names, types, and defaults, leaving path and max_bytes semantics entirely undocumented. The description offers no clarification about what path should contain or how max_bytes affects the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name: "Delegated Apple domain tool 'files_read_text_file' exposed through Apple-Tools-MCP." It does not state that the tool reads the contents of a text file from a given path, nor does it distinguish itself from sibling file tools like files_get_file_info or files_list_directory. The tool name implies the purpose, but the description itself provides no functional verb or resource explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. There are many file-related siblings, such as files_list_directory, files_search_files, and files_get_file_info, but the description does not mention any of them. There is no misleading guidance, but there is also no 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 annotations declare readOnlyHint and idempotentHint, but the description adds no behavioral context beyond that. It does not mention pagination, thread ordering, permissions, or any other runtime behavior, so it offers minimal transparency beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity here is under-specification, not conciseness. It is a single boilerplate sentence that conveys no useful information and does not earn its place as a functional description.
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?
Even though an output schema exists and annotations cover safety, the description leaves out essential information such as what constitutes a thread, how message_id is interpreted, and how limit affects results. An agent would have to infer the tool's entire behavior from its name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not compensate by explaining what message_id or limit mean or how they affect the returned thread. The only available meaning comes from the parameter names themselves, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool's name and says it is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP. It does not state that the tool retrieves a mail thread or describe any specific verb and resource beyond the title. This is essentially a tautology with no functional detail.
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 mail_get_thread versus siblings like mail_get_message or mail_search_messages. The description provides no context, prerequisites, or exclusions, so an agent cannot determine from the description alone when this tool is the right choice.
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 the annotations. While destructiveHint=true and idempotentHint=false are useful signals, the description does not explain side effects, delivery behavior, account requirements, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is boilerplate rather than concise useful content. A single sentence that only repeats the tool name does not earn its place and provides no structured information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, destructive, non-idempotent email-sending tool, this description is completely inadequate. It omits required conditions, account selection context, attachment semantics, and any distinction from sibling mail tools. An agent would have to guess essential calling details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter semantics. The input schema property names like 'to', 'cc', 'bcc', 'subject', and 'attachments' are somewhat self-explanatory, but the description offers no additional meaning or format guidance for fields like 'from_account' or 'attachments'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it restates the tool name 'mail_send_message' and says it is 'exposed through Apple-Tools-MCP' without stating what the tool does. The title hints at sending a message, but the description itself provides no functional meaning.
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 the many related mail tools such as mail_compose_draft, mail_reply_message, or mail_forward_message. No conditions, prerequisites, or exclusions are 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?
The annotations already declare destructiveHint=true, so the agent knows the operation is destructive. The description adds no additional behavioral context: it does not disclose whether deletion is recursive, whether the folder must be empty, whether it affects notes inside the folder, or whether it can be undone. However, because the destructive annotation is present and the description does not contradict it, a baseline score of 3 is appropriate; the description simply contributes nothing beyond what the annotation already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but brevity is not conciseness when it carries no information. 'Delegated Apple domain tool' is boilerplate that applies to presumably every tool in this MCP, and naming the tool again is redundant. The single sentence earns no place because it repeats the name and the MCP exposure rather than describing behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with one required parameter, no parameter documentation, and no behavioral details, the description is severely incomplete. An output schema exists, but that does not help an agent decide whether to call this tool or how to construct the folder_id. There is also no mention of how this differs from notes_delete_note, files_delete_path, or any other deletion tool in the sibling list. This is a minimum-viability failure for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining the folder_id parameter, but it says nothing about it. The schema only provides the name and type (string), leaving the agent to guess what a valid folder_id looks like, where to obtain one, and whether it refers to a Notes account-level folder or a nested folder. With one required parameter and zero coverage, the description should have provided at least a format hint or a pointer to notes_list_folders.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'Delegated Apple domain tool 'notes_delete_folder' exposed through Apple-Tools-MCP.' It merely restates the tool name and the fact that it is exposed through the MCP bridge. It does not state what the tool does, what a folder is in this context, or how it distinguishes itself from sibling tools such as notes_delete_note, files_delete_path, or reminders_delete_list. The title 'Notes Delete Folder' adds no information beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when to use this tool instead of alternatives such as notes_delete_note, notes_rename_folder, or notes_move_note. The description says nothing about prerequisites (e.g., whether the folder must be empty), the scope of deletion, or the intended workflow. An agent receives zero guidance on selecting this tool over its siblings.
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 destructiveHint=true and idempotentHint=false, but the description adds no behavioral context about deletion irreversibility, permission requirements, or side effects. It neither contradicts nor enriches 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the single sentence is largely boilerplate about being 'delegated' and 'exposed through Apple-Tools-MCP.' It does not earn its place by conveying useful operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive single-parameter tool, the description lacks any context about deletion behavior, expected input provenance, or distinction from completion/update operations. It is minimally sufficient only because the name and schema happen to make the core intent obvious.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to the sole required reminder_id parameter. The agent is left with only the bare schema field name and type, with no explanation of where the ID comes from or what it identifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name ('Delegated Apple domain tool 'reminders_delete_reminder'...') and does not independently state that it deletes a reminder. It provides no verb-resource explanation beyond what the name/title already conveys.
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 for when to call this tool or when to prefer alternatives such as reminders_complete_reminder, reminders_update_reminder, or reminders_delete_list. The description does not support selecting it over siblings.
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 declare readOnlyHint and idempotentHint, but the description adds no behavioral detail beyond that. It does not disclose what happens on invalid IDs, whether unfilled fields are returned, or any other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified rather than genuinely concise. The single sentence merely repeats the tool name and adds no functional information, so it does not earn its place.
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?
Even though this is a simple single-parameter tool with an output schema, the description is not complete enough to call correctly since it never explains what the tool does or how it relates to other reminder tools. It relies entirely on inference from the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention reminder_id at all. The agent is given no semantic context for the parameter beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and identifies it as a 'Delegated Apple domain tool' exposed through MCP. It never states the tool's function, such as retrieving a reminder by ID, so it is essentially a tautology.
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 siblings like reminders_list_reminders, reminders_update_reminder, or other reminder tools. No alternatives, exclusions, or context of use are provided.
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 read-only safety profile is covered. However, the description adds no behavioral context beyond deployment/provenance: it never states that the tool returns a list of running apps or describes any output, scope, or side-effect characteristics. It does not contradict the annotations, but it contributes essentially nothing beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but this is under-specification, not conciseness. The single sentence restates the tool name and adds an irrelevant provenance detail; it earns no place because it contains no functional information. There is no front-loaded substance to evaluate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and an output schema, the minimal required context would be a statement of what it does and how it differs from sibling tools like apple_suggest_running_apps. The description provides neither; even though complexity is low, the description is entirely uninformative and leaves the agent to guess from the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is trivially complete. Per the rubric, 0 params warrants a baseline of 4; there is nothing for the description to add here and no parameter information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it restates the tool name ('Delegated Apple domain tool 'system_list_running_apps'') and adds deployment context ('exposed through Apple-Tools-MCP') without ever stating what the tool does. The reader must infer the behavior from the name and title alone, which the description fails to convey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. A closely related sibling, apple_suggest_running_apps, exists but there is no mention of it or of any selection criteria, prerequisites, or context in which system_list_running_apps is the appropriate choice.
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 are present but the description adds no behavioral context beyond them. It does not mention that clipboard content is replaced, whether accessibility or automation permissions are required, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but its only sentence is boilerplate that does not earn its place. It provides no functional information and is under-specified rather than concisely complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description still fails to state the actual action or any practical context. An agent can infer the operation from the name and text parameter, but the description itself is not complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'text' parameter or its role. The description adds no semantic value beyond what the input schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name as a 'Delegated Apple domain tool' and says it is exposed through Apple-Tools-MCP. It does not state that the tool sets the system clipboard, beyond what the name/title already imply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool or when to prefer an alternative. Siblings such as system_get_clipboard exist, but the description does not distinguish this tool from them.
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 indicate the operation is not idempotent and not destructive, but the description adds no behavioral detail: it doesn't explain what 'enabled' does, whether system settings are persisted, whether permissions are needed, or what side effects may occur. The description contributes nothing 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but brevity is not value: the only sentence is boilerplate that restates the name and the MCP wrapper. It contains no usable information and does not earn its place.
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?
Although the parameter surface is simple, the description is still incomplete for an agent deciding whether to call this tool. It doesn't state the tool's effect, when it applies, or how it differs from related system-setting tools. The output schema does not compensate for the missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented boolean parameter. It does not mention 'enabled' at all, leaving the agent to guess whether true/false turns contrast enhancement on or off.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name and adds a generic wrapper phrase ('Delegated Apple domain tool exposed through Apple-Tools-MCP'). It does not state what the tool actually does, such as enabling or disabling the system 'Increase Contrast' accessibility setting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus sibling tools like system_set_reduce_motion, system_set_reduce_transparency, or system_set_appearance_mode. The agent must infer all selection context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond the annotations. It does not disclose that the tool changes system accessibility state, whether the change persists, or what side effects might occur. With only generic annotations and no readOnlyHint, the description leaves an agent without meaningful behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains only generic boilerplate like 'Delegated Apple domain tool' and 'exposed through Apple-Tools-MCP'. These words do not earn their place because they contribute no actionable information. This is under-specification rather than effective conciseness.
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?
Even though the tool is simple with one boolean parameter, the description is not complete enough to invoke it correctly with confidence. It does not state what Reduce Motion is, what the boolean does, or how this relates to sibling system settings tools. An agent would have to rely on naming conventions and external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required boolean parameter 'enabled' with 0% schema description coverage, yet the description provides no explanation of what 'enabled' controls. The description does not compensate for the schema gap at all, leaving the parameter semantics entirely to inference from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name as 'Delegated Apple domain tool system_set_reduce_motion' and does not say what the tool does. It fails to explain that it sets the Reduce Motion accessibility setting or toggles it via the 'enabled' parameter. This is essentially a tautology of the title and name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as system_set_increase_contrast or system_set_reduce_transparency. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavior at all. Annotations provide only openWorldHint, idempotentHint, and destructiveHint flags, and the description adds nothing beyond them, such as whether this is a read-only snapshot, what it includes, or whether it has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than conciseness. It spends words on framework exposure details instead of defining what 'system status' means or what the tool returns.
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?
Although an output schema exists and there are no parameters, the description still fails to explain the tool's purpose or scope. An agent cannot tell what 'system status' represents, how it differs from 'system_health', or when it should be called.
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 is trivially complete, so the baseline of 4 applies. The description adds nothing about parameters, but no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it repeats the tool name and states it is 'exposed through Apple-Tools-MCP' without saying what the tool does. It provides no verb, no resource, and no operational meaning beyond the title 'System Status'.
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 system_status versus alternatives like system_health, system_get_context_snapshot, or apple_get_system_context. The description is only a packaging statement, so the agent gets no help choosing among sibling tools.
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 only says the tool 'applies' a setting, which implies a mutating operation, but explains nothing about persistence, side effects, required permissions, or behavior on repeated calls despite idempotentHint=false. The annotations are sparse and the description adds no behavioral context beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler; it communicates the general action immediately. It sacrifices useful detail, but what is present is economically written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic 3-parameter updater with 0% schema coverage and many similar sibling tools, the description is far too sparse to support correct selection and invocation. The existing output schema does not compensate for missing setting identifiers, parameter semantics, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 0% description coverage and no enums, and the description does not explain what values 'setting' accepts, what 'mode' means, or how 'enabled' combines with them. An agent cannot determine the format of a valid call from this description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a concrete action ('Apply an assistant-relevant macOS setting') and a mechanism ('unified Apple control plane'), so it is not a pure tautology. However, 'assistant-relevant' and 'macOS setting' are vague, and no distinction is drawn from closely related siblings like apple_update_preferences or the many system_set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, conditions, exclusions, or alternatives are provided. Given a large sibling set with specific system_set_* tools and apple_update_preferences, the description gives an agent no basis for choosing this tool over those.
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 agent knows this is a safe, non-mutating lookup. The description adds no behavioral detail beyond what the annotations provide, and there is no contradiction. Baseline of 3 is appropriate because the description contributes nothing extra but annotations cover the 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not informative; it is essentially one sentence that restates the tool name. While brevity is present, it earns no credit because the structure lacks substance—there is no meaningful content to be concise about.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the input semantics are entirely opaque. The tool's purpose, query format, channel options, and relationship to sibling contact tools are all unexplained. An agent would likely misuse the 'query' parameter or confuse this with contact search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description gives no meaning for 'query' or 'channel'. It does not explain what format 'query' should take (contact name? phone number? email?), nor what values 'channel' accepts (phone/email?) or its default behavior. With a default of 'phone' and no enums, the agent receives no assistance beyond the raw schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it repeats the tool name and states it is an exposed Apple domain tool, but does not explain what 'resolve message recipient' actually does. It fails to convey the operational purpose (e.g., mapping a query to a contact/recipient address for messaging).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like contacts_search_contacts or apple_suggest_contacts. The description does not clarify the context in which recipient resolution is needed, nor does it exclude cases where other contact-lookup tools would be more appropriate.
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 exist (openWorldHint=false, idempotentHint=false, destructiveHint=false), so the safety profile is partly covered, but the description adds zero behavioral context: no mention that appending modifies an existing note in place, what happens with a nonexistent note_id, or any side effects. It contributes no behavioral information beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short but earns no place: it repeats the tool name and references the MCP framework instead of conveying function. This is under-specification masquerading as conciseness, not efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 required params, output schema present), which lowers the completeness burden, but the description still fails to explain the core operation, the precondition that a target note must exist, or the relationship to sibling note-mutation tools. An agent would have to guess the behavior from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining note_id and body — and it says nothing about either parameter. The names are mildly self-explanatory (an ID and a text body), but the description does not compensate for the complete lack of schema documentation, such as format expectations for note_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it quotes the tool name verbatim ('notes_append_to_note') and adds only meta-framework noise ('Delegated Apple domain tool', 'exposed through Apple-Tools-MCP'). It never states the actual function — appending body text to an existing note. The only purpose hint comes from the name itself, not the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the dozens of sibling notes tools (notes_create_note, notes_update_note, notes_delete_note). Nothing distinguishes when appending is the right operation versus updating or creating a note. No exclusion criteria or alternative routing is provided.
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 contributes zero behavioral information. Annotations (openWorldHint=false, idempotentHint=false, destructiveHint=false) provide a minimal safety profile, but the description adds nothing about what happens when a reminder is completed, whether the change is reversible, or how it relates to the inverse operation reminders_uncomplete_reminder.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the single sentence merely restates the tool name and adds no functional content, so it does not earn its place. This reads as under-specification rather than deliberate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with one required parameter and no parameter documentation beyond the field title, the description is inadequate. It omits the core semantics (that the reminder is marked completed), gives no edge-case or error behavior, and fails to point to siblings such as reminders_uncomplete_reminder that form the inverse operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single reminder_id parameter but does not. It never explains what reminder_id represents, how to obtain a valid value (e.g., via reminders_list_reminders or reminders_get_reminder), or what format is expected. The only semantic hint is the schema's own field title 'Reminder Id.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description, "Delegated Apple domain tool 'reminders_complete_reminder' exposed through Apple-Tools-MCP," merely restates the tool name and the bridge it is exposed through; it never states that the tool marks a reminder as completed. The action is only inferable from the name itself, and no distinction is drawn from siblings like reminders_update_reminder or reminders_uncomplete_reminder.
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. The description says nothing about the appropriate scenario for completing a reminder, what prerequisites exist (e.g., an existing reminder ID), or how it differs from reminders_update_reminder, reminders_delete_reminder, or reminders_uncomplete_reminder. The sibling list is present but the description makes no attempt to differentiate.
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 safety profile is covered. However, the description adds no behavioral context—no mention of output, side effects, or scope. It merely frames the tool as a 'delegated Apple domain tool,' which is structural, not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is wasted wording that does not explain the tool's function. This is under-specification rather than effective conciseness, similar to a placeholder statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool has no parameters and an output schema exists, the description fails the basic requirement of stating what the tool does. The name hints at listing reminder lists, but an agent has no way to know what a list is in Apple Reminders or how this differs from reminders_list_reminders. The definition is inadequate for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is an empty object, so schema coverage is effectively 100%. The description adds no parameter information, but none is required; the baseline of 4 for 0-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'Delegated Apple domain tool reminders_list_lists exposed through Apple-Tools-MCP' restates the tool name and domain without stating what the tool does. There is no verb, no resource, and no differentiation from siblings like reminders_list_reminders.
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 offers no guidance on when to use this tool versus alternatives. It does not reference sibling tools such as reminders_list_reminders, reminders_get_reminder, or apple_suggest_reminder_lists, so an agent cannot determine the appropriate context for selection.
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 annotations already declare readOnlyHint=true and idempotentHint=true. The description adds no behavioral context beyond those annotations—no mention of what is returned, access implications, or edge cases. This is not a contradiction, but it is also no added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not meaningfully concise—it is under-specified boilerplate that adds no functional information. The sentence does not earn its place because it only restates the tool name and domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and an output schema, the description completely fails to state the tool's purpose. An agent would have to rely entirely on the tool name to infer behavior, which is inadequate even for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. There is no parameter ambiguity or missing parameter documentation to penalize, and the schema coverage is effectively complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely says it is a 'Delegated Apple domain tool' with the tool's name quoted, never stating what it actually does. It is a tautology that restates the name and title without any verb or resource.
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 such as system_list_running_apps or apple_get_system_context. It provides no usage context, exclusions, or selection criteria.
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 carry only openWorldHint=false, idempotentHint=false, and destructiveHint=false, so the description bears the burden of explaining behavior — and says nothing. It fails to disclose that this produces a user-visible on-screen notification, may require Notification permission, and has visible side effects. The 'Delegated' framing hints at authorization but adds no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short, but its only content is the tool name and a boilerplate transport phrase, so the brevity reflects under-specification rather than efficiency. No functional information is front-loaded because none exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (three flat string parameters, output schema present), the description omits the one fact that matters: that this posts a notification to the user's screen. A single functional sentence would make this complete; the current text is interchangeable with any other 'Delegated Apple domain tool'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description offers no parameter information. Title, body, and subtitle are conventional names an agent can guess at, but neither the schema nor the description confirms their semantic role or formatting constraints. With 0% coverage, the description must compensate and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a provenance statement — 'Delegated Apple domain tool system_show_notification exposed through Apple-Tools-MCP' — that restates the tool's name without defining its action. An agent must infer from the name alone that this displays a system notification. This is a tautology with transport metadata replacing functional meaning.
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 text addresses when to use this tool or when to prefer a sibling such as system_status, system_get_frontmost_app, or system_gui_type_text. There is no mention of context like 'when the user should receive visible feedback' or exclusions for other notification-like operations. The agent receives zero routing guidance.
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 annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only/idempotent behavior is covered. The description adds no additional behavioral context about what the health check reports, what domain state it inspects, or how the result is shaped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is short, but it is under-specified rather than concise. The only sentence spends its length on the redundant framing 'exposed through Apple-Tools-MCP' and contains no functional content that earns its place.
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?
Even though the tool has no parameters, has an output schema, and is annotated as read-only/idempotent, the core semantics are missing: what 'health' means, what it checks, and how it differs from other health-check tools. An agent would have to guess from the tool name to decide whether and why to invoke it.
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 takes zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to clarify. For a no-parameter tool, the baseline is 4, and the description does not need to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool's name ('Delegated Apple domain tool 'maps_health'') and notes that it is exposed through Apple-Tools-MCP. It provides no verb or outcome indicating what the tool actually does, such as checking the health of the Maps domain. This is a tautology and does not distinguish it from the many sibling *_health tools.
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 any alternative. The description does not say that it is a diagnostic health-check for the Maps domain, nor does it mention any circumstances in which an agent should or should not call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. However, the description adds no behavioral context: it does not say what kind of results are returned, whether it probes Apple Notes, or what state it examines.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than efficient conciseness. It front-loads no actionable information and wastes the single sentence on restating the tool identity and MCP exposure rather than explaining behavior.
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?
Although the tool has no parameters and an output schema exists, the description still fails to establish what the tool does. An agent cannot confidently select notes_health over other *_health tools or understand what a successful invocation means.
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 100% schema description coverage, so there is no parameter ambiguity. Per the rubric, a zero-parameter tool receives a baseline of 4 because no parameter documentation burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name and title ('Delegated Apple domain tool 'notes_health' exposed through Apple-Tools-MCP') without stating what the tool does. There is no verb or function, only infrastructure context, so an agent cannot tell whether this performs a health check, returns diagnostics, or verifies connectivity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use notes_health versus any alternative. The sibling list shows a clear *_health pattern, but the description does not explain what a health tool is for or when it should be selected, leaving usage entirely 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 annotations already declare readOnlyHint and idempotentHint, and the description adds no behavioral context beyond that. It does not contradict the annotations, but it provides no information about what reading focus status entails or what side effects (if any) could exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but brevity here is under-specification, not conciseness. The sentence spends its words on 'Delegated' and 'exposed through' rather than on the tool's actual purpose, so it does not earn its place.
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 zero parameters, read-only annotations, and an output schema, the tool is low complexity, but the description still fails to state what the tool returns or what 'focus status' means. An agent can infer the topic from the name, but the description itself is not complete enough to support confident invocation.
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 no parameters, so the description is not required to explain parameter semantics. This is the appropriate baseline for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and packaging ('Delegated Apple domain tool... exposed through Apple-Tools-MCP') without stating what the tool actually does. It never explains that it retrieves the current Focus status, so it reads as a tautology rather than a functional description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool or when to prefer alternatives. Notably, sibling tools include apple_get_focus_status, system_status, and system_get_frontmost_app, yet the description does not differentiate this tool from them.
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 declare readOnlyHint and idempotentHint, which covers the safety profile, but the description adds no behavioral context beyond that. It does not explain what a settings snapshot contains, whether it is expensive, or any practical implications of calling it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It spends its only sentence restating the tool name and platform rather than providing useful information, so it is not appropriately concise; it is simply minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and an output schema, the description is too vague for an agent to understand what this tool returns or how it relates to sibling snapshot/status tools. Key context about the snapshot's scope and purpose is missing.
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 an empty input schema, so there is no parameter semantics burden on the description. The baseline of 4 applies because nothing needs to be explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and says it is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP. It does not state what the tool actually does, such as retrieving a snapshot of system settings, so it is essentially tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. In particular, it does not distinguish itself from similarly named siblings like system_get_context_snapshot or system_get_appearance_settings, leaving the agent without routing information.
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 provide openWorldHint=false, idempotentHint=false, and destructiveHint=false, but the description adds no behavioral context beyond the tool name. It does not disclose that the tool modifies a system accessibility setting, whether it may require permissions, or what observable effects follow. There is no contradiction with the annotations, but the description carries little of the behavioral burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, so it is concise. However, the single sentence is largely boilerplate that repeats the tool name and the MCP exposure mechanism, leaving little substantive content for an agent to use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one boolean parameter, the description is still incomplete: it does not explain what Reduce Transparency is, what side effects or prerequisites exist, or how the 'enabled' parameter maps to the desired system state. The presence of an output schema reduces the need to describe return values, but the description still fails to provide necessary selection and invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'enabled' parameter at all. Although the parameter name and title ('Enabled') are fairly self-explanatory, the description provides no confirmation that true enables Reduce Transparency and false disables it, nor any additional context about the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name: it identifies the tool as a 'Delegated Apple domain tool' named 'system_set_reduce_transparency' and says it is 'exposed through Apple-Tools-MCP.' It does not state in functional terms what the tool does, such as enabling or disabling the Reduce Transparency accessibility setting, nor does it distinguish itself from siblings like system_set_reduce_motion or system_set_increase_contrast.
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 about when to use this tool over alternatives. The description provides only provenance ('Delegated Apple domain tool... exposed through Apple-Tools-MCP') and no context such as 'use this to change Reduce Transparency in System Settings' or exclusions relative to other system_set_* or apple_update_system_setting tools.
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 annotations already declare readOnlyHint and idempotentHint, so the safety profile is established. However, the description adds no behavioral context beyond that—no scope, no permission considerations, no mention of what an agent should expect or watch out for.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is short because it lacks substance, not because it is efficiently written. Boilerplate phrases like 'Delegated Apple domain tool' and 'exposed through Apple-Tools-MCP' fill space without informing the agent.
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?
Invocation complexity is very low: there are no parameters, annotations mark the operation as read-only and idempotent, and an output schema exists. Still, the description fails to clarify what 'Finder settings' encompasses or how this fits with related settings tools, leaving the agent to rely purely on the tool name.
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%, so there is no parameter documentation burden for the description to carry. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and platform wrapper ('Delegated Apple domain tool system_get_finder_settings exposed through Apple-Tools-MCP') without saying what Finder settings are retrieved or what the tool actually does. It also does nothing to distinguish it from sibling getters such as system_get_appearance_settings or system_get_dock_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus other system getters, settings snapshot tools, or sibling Apple-domain tools. The only context is platform exposure, which is irrelevant for tool selection.
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 only indicate not-open-world, not-idempotent, and not-destructive. The description adds no behavioral context: it doesn't say whether the tool types into the frontmost app, whether bundle_id/application are required for non-frontmost apps, whether characters are sent raw or as key codes, or whether hidden windows need to be focused. A GUI typing tool needs these details to be invoked safely and correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it wastes its only sentence on a delegation wrapper ('Delegated Apple domain tool... exposed through Apple-Tools-MCP') that doesn't describe the tool's function. It is under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a GUI automation tool with three parameters and a rich sibling context, the description is incomplete. It doesn't explain how text is typed, how targeting works, what happens without bundle_id/application, or how it differs from system_gui_press_keys. The output schema and annotations do not compensate for these missing operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description itself adds zero parameter explanation. However, the parameter names and types are fairly self-explanatory: 'text' is the string to type, 'bundle_id' and 'application' target the app. Since three simple params with clear names are present, the lack of semantics is a moderate gap, not a critical one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely a generic delegation notice: 'Delegated Apple domain tool 'system_gui_type_text' exposed through Apple-Tools-MCP.' It never states that the tool types text into the system, which UI element receives it, or what action it performs. The name and title strongly imply typing, but the description itself is tautological and does not add operational meaning.
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 siblings like system_gui_press_keys, system_gui_click_button, or system_gui_choose_popup_value. It does not mention that bundle_id or application are needed to target the correct app, nor that the frontmost app may be the default target. An agent is left to infer all usage context from the parameter names.
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 annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. However, the description adds no meaningful behavioral detail beyond boilerplate, such as what 'health' means, whether it queries system state, or what kind of diagnostics it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not effectively concise: the single sentence is filler that restates the name and the MCP exposure mechanism. It does not earn its place because it conveys no operational information.
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?
Although the tool is simple with no parameters, read-only annotations, and an output schema, the description still fails to explain what calendar health checking means or when it should be used. An agent cannot determine the tool's actual role or distinguish it from sibling health tools.
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 trivially covers 100% of them, so no parameter documentation is needed. The description adds nothing about parameters, but that is acceptable given there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is effectively a tautology: it restates the tool name 'calendar_health' and title 'Calendar Health' inside a boilerplate wrapper. It does not say what the health check actually does, what resource it inspects, or what result it produces.
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 about when to call this tool versus alternatives such as reminders_health, mail_health, or system_health. No context is provided about the problem it solves or the conditions under which it should be preferred.
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 annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile, but the description adds no behavioral context of its own: nothing about what the probe inspects (e.g., contact store integrity, sync status, permissions), failure modes, or auth needs. It does not contradict the annotations, but it discloses nothing beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but this reads as under-specification rather than conciseness: it conveys essentially no functional content beyond the tool name and the server that exposes it. It does not earn its place by helping an agent decide whether to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool defined entirely by its 'health' function, the description is the sole source of functional meaning and it is empty. Although an output schema exists, the agent still cannot anticipate what the health probe reports or why it exists alongside the other *_health and contacts_* tools.
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 parameters and 100% schema description coverage, so the baseline for this dimension is 4. The description adds no parameter information, but none is needed - a parameterless tool cannot be mis-invoked based on arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name verbatim ('contacts_health') and adds only generic framing ('Delegated Apple domain tool ... exposed through Apple-Tools-MCP'). It never states what action the tool performs or what a health check evaluates, so an agent must infer the purpose from the *_health naming pattern rather than from the documentation.
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 offers no guidance on when to call contacts_health, no conditions that favor it over contacts_list_contacts or the other *_health siblings, and no exclusions. An agent receives zero decision support for selecting this tool.
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 annotations (readOnlyHint=true, idempotentHint=true) cover the safety profile, so the description's burden is lower, but it still adds zero behavioral context. It does not disclose what conditions 'health' evaluates, whether permissions or iCloud state factor in, or what failure looks like. There is no contradiction with the annotations, but also no value added beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but its single sentence does not earn its place: it repeats the tool name and describes transport instead of function. This is under-specification masquerading as conciseness, not efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The trivial invocation surface (0 params) and presence of an output schema lower the completeness bar, but the essential semantic — what 'Files Health' actually reports and when an agent should call it — is entirely absent. An agent cannot make a confident call/no-call decision from this text alone.
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 trivially covers 100% of them, so baseline 4 applies. There is nothing for the description to add about argument semantics, and it correctly does not fabricate any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description, "Delegated Apple domain tool 'files_health' exposed through Apple-Tools-MCP," restates the tool's name and title without ever stating what the tool does. It provides provenance (delegated, exposed via MCP) rather than a function, so an agent still cannot tell whether files_health checks disk space, iCloud sync health, or file-access integrity. This is essentially a tautology wrapped in transport details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever about when to use files_health versus the many relevant siblings: system_health, apple_health, files_get_icloud_status, or files_get_file_info. The description names no alternatives and gives no selection criteria, leaving the agent to guess based on the tool name alone.
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 safety profile is covered. The description adds no behavioral information at all: it does not say what is checked, what state is reported, whether any setup is required, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but it is short by omission, not by efficiency. Every sentence contains boilerplate about being 'delegated' and 'exposed through Apple-Tools-MCP' rather than useful tool information. This is under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The empty input schema, read-only/idempotent annotations, and output schema reduce the burden on the description, but the core purpose is still missing. An agent cannot know what 'messages_health' actually checks or when to prefer it over reminders_health, shortcuts_health, mail_health, or the other domain health tools.
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 100% schema description coverage, so there is nothing for the description to add. Per the zero-parameter baseline, a 4 is appropriate because no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name and title: it says 'messages_health' is an Apple domain tool but never states what it does. There is no verb or outcome, and it does not distinguish this from other domain *_health tools such as mail_health, calendar_health, or system_health.
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 about when to call this tool versus the many sibling health-check or messaging tools. The name implies a health/diagnostic role, but the description provides no conditions, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, which covers the safety profile, but the description adds no behavioral context beyond that. It does not say what settings are included, whether the result is a snapshot, whether permissions are required, or any other runtime behavior. There is no contradiction between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but shortness is not conciseness when content is mostly redundant. The sentence only restates the tool name and the fact that it is exposed via a platform. It does not front-load any useful behavioral content, so it under-specifies rather than being efficiently informative.
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?
Although the tool has no parameters and an output schema exists, the description fails to state what accessibility settings are retrieved or what the tool is for. With many sibling getter tools, an agent needs at least a one-line purpose statement to select correctly. The output schema may explain return values, but not the selection criteria for choosing 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?
The tool has zero parameters and zero required parameters, so the schema leaves nothing for the description to clarify. Per the baseline for zero-parameter tools, the description need not add parameter semantics, and it does not detract by failing to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: it restates the tool name and says it is a 'Delegated Apple domain tool' without explaining what the tool actually does. The agent is left to infer purpose from the name 'system_get_accessibility_settings,' which is some signal, but the description itself provides no verb, resource, or result semantics. It also does not distinguish this from sibling getters like system_get_settings_snapshot or system_get_appearance_settings.
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 about when to use this tool versus alternatives. No conditions, no exclusions, no mention of related getters such as system_get_dock_settings or system_get_settings_snapshot. The agent receives no help in deciding whether this is the right tool for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds no behavioral context beyond calling the tool 'Delegated'. It does not mention permissions, return behavior, or side effects, and it neither contradicts nor enriches 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but the content is filler: 'Delegated Apple domain tool' and 'exposed through Apple-Tools-MCP' communicate nothing useful beyond the tool's name. It is under-specified rather than genuinely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with no parameters and an existing output schema, the description omits the core semantic fact that this tool retrieves clipboard content. It forces the agent to infer the operation entirely from the identifier, making the definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not add parameter details, but none are needed because the input schema is empty and schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name in quotes and labels it as a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP. It never states that the tool reads or returns the current clipboard contents, so it is essentially a tautology that relies entirely on the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as system_set_clipboard or other system getters. The description only explains where the tool is exposed, not when an agent should select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered, but the description adds no behavioral detail beyond that. It does not explain what snapshot is taken, whether it reflects current state, or how it differs from other getters—the description is no more transparent than the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but its single sentence consists of generic platform boilerplate that does not earn its place. It is under-specified rather than usefully concise, offering no tool-specific information beyond the name.
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 a zero-parameter schema, an output schema, and read-only/idempotent annotations, the key missing piece is a clear statement of what the tool does. The description fails to provide that, so an agent cannot know what action to take, what the snapshot contains, or what to expect from the output.
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 0 parameters with full schema description coverage, so there are no parameter semantics for the description to add. Per the rubric, zero-parameter tools get a baseline of 4, and the absence of parameter detail is not a weakness here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a boilerplate wrapper: it restates the tool name and says it is a 'Delegated Apple domain tool' exposed through Apple-Tools-MCP, but it never states what the tool actually does or what a context snapshot is. This is essentially a tautology with no verb+resource and no differentiation from siblings like system_get_system_context or system_get_settings_snapshot.
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 or when to choose an alternative. Sibling tools such as system_get_system_context, system_get_settings_snapshot, and system_status are left completely undifferentiated, so the agent must infer usage solely from the tool name.
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 annotations already declare readOnlyHint and idempotentHint, so the agent knows the call is safe and repeatable. However, the description adds no behavioral context beyond that: it doesn't explain what health data is returned, what checks are performed, whether permissions are needed, or what side effects (if any) occur. There is no contradiction with annotations, but the description contributes no disclosure of its own.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not meaningfully concise: its only sentence repeats the tool name and generic MCP exposure, which applies to every tool in the server. The space is wasted on provenance instead of being used to state the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has no parameters, annotations for safety, and an output schema, the description still fails to answer the central question: what does system_health do and when should an agent call it? Without that, the agent cannot reliably select this tool over system_status or other health/status siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is an empty object with 100% coverage, so there is nothing for the description to clarify. The baseline for a zero-parameter tool is 4, and the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool's name and provenance: "Delegated Apple domain tool 'system_health' exposed through Apple-Tools-MCP." It never says what the tool actually does, what 'system health' means, or what kind of result it produces. This is essentially a tautology of the title/name with no functional verb or resource behavior.
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 about when to use this tool versus relevant siblings such as system_status, system_get_context_snapshot, apple_get_system_context, or the various *_health tools. The description provides no trigger condition, no exclusions, and no mention of alternatives.
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 annotations already indicate readOnlyHint and idempotentHint, so the safe, read-only nature is covered. The description adds no behavioral context such as what a 'settings domain' is, whether enumeration is local, or how results are scoped. It does not contradict the annotations, but it provides no additional transparency value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short, but it is empty filler that simply repeats the tool name. Under-specification is not conciseness, and the sentence does not earn its place in the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having zero parameters and an output schema, the description fails to clarify what 'settings domains' are or how this tool relates to sibling preference and settings tools. The agent is left to infer semantics from the name alone, which is risky for discoverability. The output schema may define the return shape, but it cannot explain when or why to 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?
The tool has zero parameters, so the schema fully covers the calling contract. The absence of parameter information in the description is acceptable because there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name verbatim and only adds the unhelpful framing 'Delegated Apple domain tool...'. It never explicitly states that the tool lists available settings domains, so an agent must infer the function from the name alone. This is closer to a tautology than a purpose statement.
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 call this tool instead of related siblings such as system_read_preference_domain, system_get_settings_snapshot, or apple_get_preferences. There is no context about expected use cases or exclusions, so an agent has no basis for selecting among alternatives. The description is neutral but unhelpful.
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 annotations already indicate readOnlyHint=true and idempotentHint=true, but the description adds no behavioral context beyond the bare name. It does not mention return shape, scope of folders, sorting, permissions, or any other runtime behavior, and the 'Delegated' phrasing is architectural boilerplate rather than useful behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the only sentence mostly repeats the tool name and adds generic 'Delegated ... exposed through Apple-Tools-MCP' filler. It is not meaningfully concise because it packs no useful information.
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 to invoke: no parameters, read-only annotations, and an output schema exist. However, the description still fails to explain what Shortcuts folders are or what the result represents, leaving the agent to infer the entire purpose from the tool name.
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 an empty input schema, so there are no parameter semantics for the description to clarify. This matches the baseline of 4 for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool's name as 'shortcuts_list_folders' and wraps it in 'Delegated Apple domain tool ... exposed through Apple-Tools-MCP' boilerplate. It never directly states what the tool does, such as listing folders in the Shortcuts app, so an agent must rely on the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of related tools such as shortcuts_list_shortcuts, shortcuts_view_shortcut, apple_list_shortcuts_for_capability, or notes_list_folders. The description provides no usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, and the description adds no behavioral detail beyond saying the tool is 'delegated' and 'exposed'. It does not describe what data is returned, whether sampling is involved, or any other operational nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but hollow; it is generic boilerplate that could apply to nearly any delegated Apple tool. It does not earn its place because it contributes no substantive information.
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 very simple with no parameters, a read-only annotation, and an output schema, so invocation is low-risk and structurally complete. However, the description still fails to state the core purpose, leaving the agent to infer everything from the tool name.
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 an empty input schema, so there is no parameter semantics for the description to explain. The baseline for a no-parameter tool is satisfied; nothing is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and calls it a 'Delegated Apple domain tool'; it never says what the tool actually does, such as retrieving battery status. This is essentially a tautology rather than a functional explanation.
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 system_status, system_health, or system_get_context_snapshot. No context, prerequisites, or exclusions are provided.
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 annotations already disclose that the tool is read-only and idempotent, and the description adds no behavioral context beyond that. Phrases like 'Delegated Apple domain tool' and 'exposed through Apple-Tools-MCP' are packaging metadata, not behavior. There is no contradiction with the annotations, but the description contributes nothing about what happens when called, what the output represents, or what side effects (if any) to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than usefully concise. The sentence spends its words restating the tool name and plumbing ('Delegated Apple domain tool', 'exposed through Apple-Tools-MCP') without earning its place by conveying what the tool does. A useful one-sentence definition could have been equally concise while providing 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?
For a zero-parameter read-only getter with an output schema, the description does not need to explain return values or parameters. However, it still omits a direct statement of what 'Dock settings' means in this context and does not distinguish this from related getters. The tool is simple enough that an agent may infer intent from the name, but the description alone is not fully 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?
The tool accepts zero parameters, so the description has no parameter semantics burden. Schema coverage is effectively 100% because there is nothing to document. The baseline for zero-parameter tools is 4, and no missing parameter information needs to be compensated for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only restates the tool name and its deployment context ('Delegated Apple domain tool ... exposed through Apple-Tools-MCP'), without stating what the tool does. It is a tautology: it says the tool exists and is named this way, but never explains that it retrieves Dock settings. The title and name imply the purpose, but the description itself provides no actual semantic content.
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 system_get_settings_snapshot, system_get_appearance_settings, or system_get_finder_settings. The description does not mention any selection criteria, exclusions, or prerequisites, leaving the agent without direction about the appropriate context for invoking this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide openWorldHint, idempotentHint, and destructiveHint, so the description needs to add behavioral context beyond those flags. 'Bounded GUI fallback actions' hints at constraints, but the description does not disclose what actions are allowed, what side effects GUI manipulation may have, or any permission or accessibility prerequisites. This leaves an agent uncertain about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and contains no filler, but it is terse to the point of being under-specified. For an 11-parameter tool, a one-sentence description is not appropriately sized and lacks any structure such as parameter guidance or examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a useful fallback-routing rule and the output schema may cover return values, but it is far from complete for a tool with 11 parameters and no parameter documentation. An agent cannot correctly invoke the tool without knowing valid actions and parameter combinations. Some usage context exists, but the operational picture is largely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description names none of the 11 parameters. An agent receives no help understanding the required 'action' values or the roles of 'menu_path', 'modifiers', 'bundle_id', 'application', and the other parameters. With zero schema documentation, the description needed to compensate and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description conveys that this is a fallback GUI control mechanism for Apple apps, but 'unified Apple control plane' and 'bounded GUI fallback actions' are abstract and do not say concretely what the tool performs, such as clicking menu paths, pressing keys, or typing text. It distinguishes from native app-domain tools, but not from the many system_gui_* siblings, so an agent would still need to open the schema to understand its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the trigger condition: use when a native app-domain tool cannot complete the task. This gives a clear selection rule and implies this tool should not be the first-line approach. It does not name specific sibling alternatives, but the native-vs-fallback distinction is sufficient for routing.
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 read-only and idempotent behavior, lowering the bar. The description adds only the notion of 'current Apple data surfaces' and the fallback context; no additional behavioral details such as return format, ordering, or error conditions are disclosed. 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, but the first is a fragment that mostly restates the title. The second sentence is informative about the fallback purpose. Slightly under-specified but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple suggest tool with an output schema and safety annotations, the description covers the primary use case but omits parameter semantics and any reference to sibling tools like notes_list_folders. Given the low schema coverage, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (limit, query) have no description in the schema (0% coverage), and the tool description makes no mention of how they behave. The description completely fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says the tool suggests note folders, but the phrasing is a noun phrase rather than an actionable statement. It does not explain what the tool returns or what 'current Apple data surfaces' means. The resource is clear from the name, but the description adds little beyond the title.
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?
Explicitly identifies its use as a completion fallback for clients without MCP completion support. This provides a clear context for when to use the tool, though it does not name alternatives like notes_list_folders or provide 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 description usefully discloses that the tool will prompt for missing details, which is a key behavioral trait beyond the annotations. However, it does not explain whether the event is created immediately after prompting, whether confirmation is required, or how the interactive flow terminates.
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 efficient sentence that front-loads the primary action and the key interactive behavior. It is concise and avoids repetition, though it could afford slightly more useful detail without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an interactive creation tool with seven optional parameters and a sibling non-interactive equivalent, the description is too sparse. It does not clarify how missing fields are collected, what happens if the user provides no details, or when calendar_create_event is the better choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of any of the seven parameters like start_iso, end_iso, calendar_id, or all_day. The description does not compensate at all for the schema's lack of descriptive detail.
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 action ('Create a Calendar event') and adds the interactive behavior of asking for missing details. It is clear about the core purpose, though it does not explicitly differentiate itself from the sibling calendar_create_event tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'asking for missing event details when needed' implies this tool is intended for incomplete event creation requests, but it never states when to prefer this over calendar_create_event or mentions any exclusions or alternatives. The usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations limited to openWorldHint, idempotentHint, and destructiveHint, the description must disclose side effects, but it only restates the core action of persisting defaults. It does not state whether omitted parameters are left unchanged, whether existing defaults are overwritten, or what side effects occur beyond persisting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource. The list of default categories is informative and 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 15 optional parameters and no schema descriptions, this is too sparse. It leaves critical invocation questions unanswered: are all parameters optional, do nulls clear defaults or leave them unchanged, and how do sibling tools relate? An agent could call it with the wrong parameter group or without understanding partial updates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides broad category mapping (lists, folders, calendars, archive mailboxes, communication routing) that helps group the 15 parameters, but it does not explain the id-vs-name pairs, whether IDs or names take precedence, or the relationship between default_mail_account and preferred_communication_channel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Persist') with a clear resource ('assistant defaults') and enumerates the included domains: default lists, folders, calendars, archive mailboxes, and preferred communication routing. This distinguishes it from sibling tools like apple_get_preferences (reading) and apple_update_contact_preferences (contact-specific), though it does not explicitly name a sibling contrast.
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 explicit guidance on when to use this tool versus alternatives such as apple_get_preferences, apple_detect_defaults, or apple_update_system_setting. The intended use is only implied by the verb 'Persist' and the list of default categories; there are no exclusions, prerequisites, or when-not-to-use rules.
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 provide only basic hints, so the description carries additional weight. It discloses that the tool creates two artifacts (a reminder and an archival note) and uses assistant defaults, which is meaningful behavioral context. However, it does not clarify side effects such as whether the source email is also archived, whether repeated calls duplicate items, or how defaults affect results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core purpose, the default-driven behavior, and the two outputs quickly and efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, two side effects, and dependency on assistant defaults, this description is too sparse. It does not explain the boolean flags, the meaning of 'archival note,' prerequisites like Mail permissions, or whether a preview step should be used first. Even with an output schema present, the agent lacks enough context to invoke this tool confidently in varied situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions 'assistant defaults' without explaining parameter roles. It does not clarify how create_reminder and create_note interact with reminder_title and note_title, what format due_date expects, or that message_id identifies the source email.
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 and resource: turning an email into a reminder and an archival note. This clearly differentiates it from pure reminder-creation or note-creation tools, though it does not explicitly distinguish it from the apple_preview_follow_up_from_mail sibling.
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 implies this is the tool to use when assistant defaults are acceptable, but it gives no explicit when-to-use or when-not-to-use guidance. It does not name alternatives like apple_create_reminder_with_defaults, apple_create_note_with_defaults, or apple_archive_message, so an agent must infer the right context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: readOnlyHint=true declares a read-only operation, but the description says 'persist it if found,' which describes a state-changing side effect. This directly conflicts with the annotation and misleads the agent about whether calling the tool mutates state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the primary verb and delivers both the detection scope and the persistence behavior with no wasted words. Every element 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?
For a zero-parameter tool with an output schema, not much is needed, but the description leaves important behavior underspecified: what 'persist' means (where the preference is stored), what happens when no folder is found, and whether repeated calls overwrite. The read-only contradiction further compounds the incompleteness.
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, there is nothing the schema or description could mis-specify, so the no-parameter baseline of 4 applies. The description correctly avoids inventing parameter details that do not exist.
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 ('Detect') and resource ('preferred Notes folder for daily and weekly digests'), with an added action of persisting the result. It is clear what the tool targets, but it does not differentiate from the closely related siblings apple_set_digest_folder and apple_ensure_digest_folder, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the nearly identical digest-folder siblings (apple_set_digest_folder, apple_ensure_digest_folder). The description implies a purpose but provides no conditions, exclusions, or alternatives, leaving the agent to guess when 'detect and persist' is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral context that this action persists a configuration choice for future digest use, which goes slightly beyond the annotations. However, it does not disclose overwrite behavior, validation failures, or the implications of passing folder_name and account_name, even though annotations are minimal and unhelpful for a mutation.
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 senttence that leads with the verb 'Persist' and names the object and purpose. Every word contributes meaning, with no redundant phrasing.
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?
Although the tool is simple, the description leaves significant gaps: parameter relationships are undefined, and there is no guidance for choosing this tool over related sibling tools. The output schema may describe the return value, but it cannot compensate for missing invocation and parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it provides no parameter-level semantics. It gives no explanation of how folder_id relates to folder_name or account_name, nor what each optional field is for, leaving the agent to guess from property names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Persist') and identifies the resource ('dedicated Notes folder' for daily/weekly digests'), making the tool's core purpose clear. It does not explicitly contrast itself with similar siblings like apple_ensure_digest_folder or apple_detect_digest_folder, so it stopsshort of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus alternatives such as apple_ensure_digest_folder or apple_detect_digest_folder. The description states what the folder is used for, but not when this setter should be invoked over related tools.
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 provide idempotentHint=false, openWorldHint=false, and destructiveHint=false but no readOnlyHint, so the description's mention of replace/add/remove usefully signals mutating behavior. However, it does not explain the semantics of replacement, whether removing tags is reversible, or what happens with Apple Files synchronization. The description partially carries the behavioral burden but leaves important side effects unspecified.
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 operations and target resource. There is no repetitive or filler content; every phrase adds meaning.
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?
Although an output schema exists and the tool has only three parameters, the description is too thin for correct invocation. An agent still needs to know valid action strings and how the tags list behaves under add, replace, and remove actions. The tool is simple, but the invocation contract is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the action parameter is a free-form string with no enum or description. The description lists four natural-language verbs but does not map them to the actual action values, especially the default 'get' versus the described 'read'. The interaction between the tags array and each action is also undocumented, leaving invocation ambiguous.
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 verb and resource: read, replace, add, or remove Finder tags on a file or folder through Apple Files. It is specific enough to understand the tool's core function, though it does not explicitly differentiate itself from sibling tag tools like files_get_tags or files_add_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as files_set_tags, files_add_tags, or files_remove_tags. There is no stated context, prerequisites, or exclusion criteria, so an agent cannot reliably decide between this tool and related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Ensure ... exists, creating it when necessary,' which implies an idempotent operation, but the annotations declare idempotentHint: false. That is a direct contradiction. The description also reveals a preference-write side effect, but the idempotency conflict forces a low score.
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 with no filler. It states the guarantee, the conditional creation, and the preference persistence efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists and complexity is low, the description leaves important invocation details unresolved because the schema has zero descriptions. An agent cannot confidently know how to specify the account or folder name or whether the tool operates on a default account. It is not complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds nothing about folder_name or account_name. The defaults in the schema help, but the description fails to compensate for the low coverage; in particular, account_name=null is left ambiguous (default account? all accounts? current account?).
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 names a specific resource and action: ensure a dedicated Notes folder for daily and weekly digests exists, creating it if needed. It also adds the key side effect of persisting the preference, which separates it from siblings like notes_create_folder or apple_set_digest_folder.
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 clearly situates the tool: it is meant for setting up the folder behind daily and weekly digests. It doesn't explicitly name alternatives or exclusions, but the intended context is clear enough for an agent to select it over generic folder-creation tools.
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 no side-effect disclosure is needed. The description adds that results are 'likely' duplicates, indicating heuristic rather than exact matching, and frames the tool as a pre-action disambiguation step. It does not disclose output shape or the distinction between all duplicates and merge candidates.
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 front-loaded sentence states action, resource, and purpose with no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no required parameters and has an output schema, but because schema description coverage is 0%, the description must clarify parameters and the difference between querying and merge candidates. It does not, leaving an agent uncertain about invocation options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentiones none of the two parameters. 'query' and 'merge_candidates_only' remain unexplained; the description adds no meaning beyond the bare property names and defaults.
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?
Clearly states a specific action (find likely duplicate contacts) and resource (Apple Contacts) plus intended purpose (disambiguate people before acting). It does not explicitly contrast with sibling tools like contacts_search_contacts or apple_prepare_unique_contact, so it misses a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'so assistants can disambiguate people before acting' implies a natural trigger: run before acting on a person when duplicates may exist. It provides contextual timing but no explicit when-not or alternative routing, such as when to use contacts_search_contacts or apple_prepare_unique_contact.
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 covered. The description adds useful context about what the briefing aggregates, but it does not disclose additional behavioral traits such as side effects, permission needs, or output characteristics. 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?
A single front-loaded sentence that states the action, scope, and key inputs without filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and read-only/idempotent annotations reduce the need for return-value and side-effect explanation. However, the missing parameter semantics and lack of sibling-selection guidance leave an agent to guess about mail filtering behavior and when this tool is preferred over the weekly briefing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain mail_limit and mail_query, but it only references 'Mail highlights' as a source. The parameter names and defaults provide some hint, but this is not enough to compensate for the complete lack of schema and description detail.
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 action and resource: 'Generate a daily Apple briefing', and names the data sources ('today's context, domain health, and Mail highlights'). It distinguishes from apple_generate_weekly_briefing through the word 'daily', though it does not explicitly name the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool vs alternatives like apple_generate_weekly_briefing, apple_overview, or apple_triage_communications_task. The word 'daily' implies a cadence, but there are no explicit conditions, exclusions, or decision criteria.
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 communicate read-only vs. destructive vs. idempotent characteristics, and the description adds little beyond restating the core action. It does not disclose activation vs. launch behavior, error cases, or what happens when both name and bundle identifier are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no filler, front-loaded with the action and containing only the key identification method. It is easy to parse and retains no redundant information.
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 two-parameter launch tool with an output schema, the description is largely usable but not complete. It fails to state that at least one parameter is needed, and it does not address the overlapping presence of system_open_application, which leaves an agent uncertain about correct routing.
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 descriptions are 0% covered, so the description's phrase 'using its name or bundle identifier' does add useful mapping to the two optional parameters. However, it does not clarify whether at least one is required, which takes precedence if both are supplied, or how exact the name/bundle identifier match must be.
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 action ('Open an application'), the target resource, and the means of identifying it ('name or bundle identifier'). However, it does not differentiate itself from the sibling tool system_open_application, which appears to serve the same core purpose.
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 prefer this tool over system_open_application or other launching/control tools in the sibling list. The description provides no exclusions, prerequisites, or alternative conditions.
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 cover non-destructiveness and open-world behavior, and the description does not contradict them. It adds only the mechanism 'through Apple Files' and the file-or-folder scope, but does not disclose side effects such as opening a Finder window, requiring an existing path, or authorization behavior. This is a modest addition over 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?
One short sentence with no filler and the action verb front-loaded. It clearly communicates the purpose without redundant wording.
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 has an output schema plus annotations, so the description does not need to explain return values. However, it omits any guidance on path requirements and the key sibling distinction from files_reveal_in_finder. The definition is adequate for basic invocation but not fully complete for correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description is the only source of parameter meaning, but it only implies that 'path' identifies a file or folder. It does not specify whether the path must be absolute, whether it must already exist, or what path formats are accepted. The single parameter is therefore only minimally documented.
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 names a specific action ('Reveal'), a resource ('file or folder'), and a target context ('in Finder through Apple Files'), so an agent understands what the tool does. However, it does not distinguish itself from the closely named sibling files_reveal_in_finder, so it stops short of full differentiation.
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 statement about when to use this tool rather than files_reveal_in_finder, apple_open_file_path, or files_open_path. The description gives no conditions, exclusions, or alternatives. An agent must infer appropriate use purely from the name.
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 the useful context that this is a completion fallback. It does not describe the data surfaces or suggestion behavior in detail, but there is no contradiction with 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, and the second sentence is genuinely useful. However, the first sentence largely restates the tool name and adds only the vague 'current Apple data surfaces' phrase, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and annotations cover the return shape and safety profile, but the description leaves parameter semantics and routing versus sibling tools underspecified. An agent could call the tool with defaults, but it would not understand how to use query or limit effectively from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention 'limit' or 'query' at all. The parameter names are somewhat self-explanatory, but the description adds zero meaning about their semantics, accepted formats, or how they affect suggestions.
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 that the tool suggests message conversations and frames it as a completion fallback, which gives a clear verb, resource, and role. It does not fully contrast with sibling suggest tools, but the resource is specific enough to avoid most confusion.
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 explicitly identifies the trigger condition: clients without MCP completion support should use this as a fallback. It does not explicitly mention alternatives like messages_list_conversations or other suggest tools, so exclusion guidance is incomplete.
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 as true, so the safety profile is covered structurally. The description adds the behavioral context that this is a completion fallback and that it draws on current Apple data surfaces, but it does not disclose limitations such as whether suggestions are unvalidated, how data freshness works, or whether results are purely local. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two sentences with no redundant filler. The completion-fallback context is useful and placed in the second sentence, though the first sentence is somewhat tautological with the tool name and could have been more informative. Overall it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool in a large family of suggest_* and maps_search_* tools, the description omits the key selection criteria: when to choose apple_suggest_places over apple_maps_search_places_strict or maps_search_places. It also does not clarify what 'current Apple data surfaces' includes or how query and limit shape results. The presence of an output schema helps, but the operational context is still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining query and limit. It does not explicitly define query as the partial place-name fragment or limit as the maximum number of suggestions. The 'completion fallback' phrase implies a query-to-suggestions relationship, but the semantics are left largely to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation is 'Suggest Places' using Apple data surfaces and clarifies it is a completion fallback, which gives some sense of purpose beyond the tool name. However, it is vague about what 'current Apple data surfaces' means and does not explicitly say it returns autocomplete-style place suggestions for a partial query. It also does not distinguish itself from nearby sibling tools like apple_maps_search_places_strict or maps_search_places.
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 usage context: use this tool as a completion fallback for clients that lack MCP completion support. This is a specific when-to-use signal. It does not mention alternatives or exclusions, such as when to prefer a strict place search instead, 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'persist them if missing', which implies a state-changing write operation, while the annotations declare readOnlyHint=true. This is a direct contradiction about whether the tool has side effects, so an agent cannot reliably predict the tool's behavior. Annotation Contradiction flag set.
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, no repetition of the title, and no unnecessary detail. Every phrase adds meaning: detection scope and conditional persistence.
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 zero-parameter tool with an output schema, the core action is stated. However, the description never defines what 'sensible default targets' are or the exact persistence semantics, and the contradiction between readOnlyHint and 'persist' leaves a critical behavioral ambiguity unresolved.
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%, so there is nothing for the description to add about parameter semantics. Baseline for zero-param tools is 4, and the description avoids inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Detect') and names the resources (mail, calendar, reminders, notes targets), then adds the persistence behavior ('persist them if missing'). This clearly distinguishes it from sibling detection tools like apple_detect_digest_folder, though it does not explicitly contrast with related preference tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'if missing' implies an initialization or setup use case: run this when default targets may be absent. However, there is no explicit when-to-use or when-not-to-use guidance, and no sibling alternatives are named to help the agent choose between this and tools like apple_get_preferences or apple_suggest_calendars.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile of a read-only status check, so the bar for the description is lower. The description adds only the 'unified Apple control plane' routing context and the odd 'truthful' claim, which is vague rather than a concrete disclosure. It does not contradict the annotations, since 'Return' is consistent with readOnly and idempotent.
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 short sentence that front-loads the verb 'Return' and contains no padding. The word 'truthful' is a confusing qualifier that could be dropped, but the overall size is appropriate for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool with an output schema present, the description plus annotations are largely sufficient: safety is carried by the annotations and return values are documented by the output schema. The remaining omissions — what 'Focus support metadata' actually contains and how this differs from system_get_focus_status — are purpose/usage gaps rather than missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the 0-param baseline of 4 applies and there is nothing the description must explain. Schema description coverage is effectively 100% because no parameters exist. The description appropriately adds no parameter-related noise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and names a resource ('Focus support metadata'), so it identifies an action and target. However, 'Focus support metadata' is vague — it is unclear whether this returns the current Focus mode, available modes, or whether Focus is supported at all — and the qualifier 'truthful' is confusing. It also does nothing to distinguish this tool from the nearly identical sibling system_get_focus_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The sibling list contains system_get_focus_status, which sounds like the same function, yet the description never explains when to prefer this unified-control-plane variant over the system_* one. There is no exclusion or conditional context anywhere in the text.
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=false. The description adds useful behavioral context: contacts are resolved, assistant defaults are applied, and the channel may be Messages or Mail. It does not describe confirmation behavior, failure modes, or side effects, but it does add 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 sentence with no filler, front-loading the action and core scope. Every word contributes meaning, making it efficient 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?
Given six parameters, zero parameter descriptions, a destructive action, and a large sibling family including direct send tools, the description is too thin for confident selection and invocation. The output schema covers return values, but parameter meaning and sibling differentiation remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It only hints at recipient resolution and default channel behavior, leaving subject, attachments, and from_account semantically unexplained. Most of the six parameters gain no meaning from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Send') and identifies the resource ('a communication through Messages or Mail') plus the key mechanisms ('Contacts resolution and assistant defaults'). It is clear and not a tautology, though it does not explicitly distinguish itself from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when sending via Messages or Mail with Contacts resolution and assistant defaults. However, it never explicitly states when not to use it or names alternatives like mail_send_message or messages_send_message, leaving some routing to 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, covering the safety profile. The description adds that the tool is a completion fallback and uses 'current Apple data surfaces', which provides some context, but it does not explain return behavior, sorting, or whether app names are localized or filtered.
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 only two sentences and wastes little space. The first sentence is somewhat redundant with the tool name, but the completion-fallback context in the second sentence adds meaningful value.
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, read-only, has no required parameters, and an output schema exists, so the description does not need to explain return values. Still, the lack of parameter guidance and the absence of any contrast with system_list_running_apps leave room for an agent to misuse or under-use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no explanation of 'limit' or 'query'. The parameter names and defaults make the intent partially inferable, but the description does not compensate for the missing schema descriptions, leaving behavior around query matching and limit semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (suggest) on a specific resource (running apps) and notes the data source, which is enough to understand the core function. However, it does not explicitly differentiate itself from the sibling system_list_running_apps, and the phrase 'current Apple data surfaces' is vague.
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 one clear usage context: it is a completion fallback for clients without MCP completion support. It does not state when to prefer system_list_running_apps over this tool, nor when not to use it, so the guidance is useful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a meaningful behavioral detail beyond the annotations: the operation is a persistent write that will influence future Apple-Tools routing decisions, not a one-off send or preview. However, it omits important update semantics such as whether existing preferences are replaced or merged, what clear_existing does, and whether unmentioned preferences are left untouched. The annotations only provide idempotent/destructive hints, so these gaps matter.
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 the action and resource front-loaded, and the purpose clause is useful rather than filler. It is concise without sacrificing the core message.
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?
Even with an output schema present, the tool has six input parameters with zero schema-level descriptions, and the description does not clarify the key update semantics or parameter relationships. An agent would struggle to know how clear_existing interacts with the preferred_* fields and would be uncertain which preference parameter applies to which communication scenario, making the definition incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only paraphrases the preference fields as 'preferred communication routing' and 'channel and target'. It does not explain contact_id, clear_existing, or the distinction among preferred_message_channel, preferred_communication_channel, and preferred_message_target, which are the least obvious parameters and most likely to cause incorrect invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Persist') and specifies the resource ('preferred communication routing for a specific contact'), and it explains the downstream purpose: letting Apple-Tools choose the right channel and target. However, it does not explicitly distinguish itself from sibling tools like apple_update_preferences or contacts_update_contact, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to persist a specific contact's communication routing preferences for later Apple-Tools use. But it does not explicitly state when not to use it, nor does it name alternatives such as apple_update_preferences or contacts_update_contact, leaving some selection ambiguity.
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 mark the tool readOnly and idempotent; the description adds a useful operational behavior: failing closed if the Maps helper is unavailable. This goes beyond the annotations and shapes expectations, even though it does not specify the exact error shape.
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 concise sentence with the action front-loaded and no unnecessary words. The fail-closed behavior is appended cleanly without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists and the three parameters are simple enough for basic calls, but the description omits parameter format guidance and does not differentiate this tool from maps_get_directions. That is adequate for a low-complexity tool, but not fully 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?
Schema description coverage is 0% and the description gives no detail on origin/destination format or allowed transport values. The parameter names are self-explanatory, but the description adds no meaning beyond them and does not compensate for the missing schema descriptions.
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 action and resource: getting directions via Apple Maps, and adds a distinctive failure-mode qualifier ('fail closed if the Maps helper is unavailable'). It is clear, but it does not explicitly contrast with the sibling maps_get_directions, so the strict/non-strict distinction is left mostly to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over maps_get_directions or maps_open_directions_in_maps. 'Fail closed' describes behavior, not selection criteria, so the agent is left to infer when this strict variant should be preferred.
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 cover the safety profile (readOnlyHint=true, idempotentHint=true), and the description does not contradict them. The description adds only mild context via 'aggregated...using the standalone domain resources,' hinting that the tool pulls across multiple domain resources, but discloses no further behavior. With annotations doing the heavy lifting, this is adequate but not additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single 12-word sentence that front-loads the core action. The trailing 'using the standalone domain resources' is somewhat vague and could be dropped or clarified, but the overall length is appropriate for a 0-parameter 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 0-parameter, read-only tool with an output schema, the description is nearly sufficient for invocation. The key gap is guidance on when to choose this tool over siblings like apple_get_system_context or apple_generate_daily_briefing, plus clarification of what the aggregated overview actually includes.
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 takes zero parameters, so the input schema has nothing to explain; per the rubric, 0 params earns a baseline of 4. The description properly avoids inventing parameter detail that doesn't exist.
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?
States a specific verb ('Return') and resource ('aggregated Apple ecosystem overview'), so an agent knows what action is offered. However, it does not distinguish itself from similar siblings like apple_get_system_context, apple_health, or apple_generate_daily_briefing, and the phrase 'standalone domain resources' is vague jargon.
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?
Provides no guidance on when to use this tool versus the many overlapping siblings (apple_get_system_context, apple_health, apple_generate_daily_briefing, apple_get_preferences). No when/when-not conditions or alternative routing are given, leaving the agent to guess which overview-ish tool fits.
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 description mainly reinforces that this is a preview rather than an actual create. It adds some behavioral context by specifying that the configured default notes folder is used, but does not describe edge cases such as missing configuration or folder_id override behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler. The key qualifying behavior (preview) is front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The provided annotations and output schema cover safety and likely return shape, so the minimal description is workable. However, it omits prerequisites or caveats around the configured default notes folder and does not explain whether the optional folder_id parameter overrides it, which an agent may need to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter semantics, but it only mentions the default notes folder. It does not clarify how title, body_html, body_text, tags, or especially folder_id interact with the default-folder behavior, leaving important invocation semantics ambiguous.
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 action ('Preview how Apple-Tools will create a note') and scopes it to the configured default notes folder. This clearly distinguishes it from actual creation and from previewing other resources, though it does not explicitly name the corresponding create alternative.
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 use of 'Preview' implies a dry-run before actual note creation, and the reference to defaults sets context. However, there is no explicit guidance about when to use this tool instead of apple_create_note_with_defaults or how it relates to the other apple_preview_* tools.
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 cover the safety profile (idempotentHint=false, destructiveHint=false, openWorldHint=false), and the description adds routing context without contradicting them. But it omits meaningful behavioral facts for a tool that executes user-defined automation: that running a shortcut may trigger arbitrary side effects, and that `dry_run` exists as a preview path. The description adds only modest 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single 22-word sentence that front-loads the core purpose and places the conditions after it. There is no wasted prose or repetition of the title. It earns a 4 rather than 5 because the same space could have carried one more useful fact (e.g., dry-run behavior or a side-effect note) without losing tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a router/executor with five parameters, one required opaque field, and zero schema description coverage, a one-sentence description is insufficient. The agent is left without guidance on how to phrase `request`, when to set `dry_run`, how routing decisions resolve when no shortcut is named, and how this relates to the sibling `shortcuts_run_shortcut`. An output schema exists but does not compensate for the missing usage semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the five parameters. The required `request` field is completely unexplained — an agent cannot tell whether it is a natural-language instruction, a routing query, or an action name. `input_text`, `input_paths`, `shortcut_name_or_identifier`, and `dry_run` are guessable from names but receive no semantic confirmation from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's role — using Apple Shortcuts as an explicit bridge — and names its two trigger conditions (insufficient native coverage, direct shortcut naming), which distinguishes it from the family of native apple_* tools. However, the verb 'use' is less specific than 'runs' or 'executes', and the operational distinction between the routing and the running behavior implied by the name is left implicit.
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 two explicit when-to-use conditions: 'when native Apple MCP coverage is insufficient' and 'when the user names a shortcut directly.' This effectively implies the when-not case (use native tools when coverage is sufficient). It does not name the overlapping sibling `shortcuts_run_shortcut` or state how to choose between them, so the guidance is strong but not fully explicit about alternatives.
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 provide readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful context about cross-app aggregation and unread Message sources, but it doesn't clarify whether message/mail contents are only read locally or whether the summary triggers any side effects (e.g., clearing unread status). Given annotations, this is acceptable 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, tightly written sentence that front-loads the core action and scope. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no schema descriptions, the definition is incomplete for correct invocation. The agent cannot determine how mail_query and the limits interact, what the default '*' means, or how the summary is scoped. The output schema exists and covers return values, but the input semantics are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention mail_limit, mail_query, or conversation_limit at all. Parameter names are somewhat self-explanatory, but the description adds zero meaning about how queries or limits behave, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and names a concrete resource ('cross-app communications triage summary') with explicit sources ('unread Messages and Mail search results'). This clearly distinguishes the tool from sibling tools by stating exactly what it produces and from where.
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 use case—summarizing communications from Messages and Mail—but does not state when to choose this tool over alternatives like mail_search_messages or messages_search_messages. There is no explicit when-to-use/when-not-to-use guidance, only an implied 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?
The annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds the 'likely' qualifier, which signals fuzzy/ranking behavior rather than exact matches — a useful behavioral nuance. It does not disclose match criteria, ordering, or no-match behavior, so the added context is modest 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the verb and resource front-loaded ('List likely shortcuts') followed by the purpose clause. No filler or repetition of the schema. The purpose clause is slightly long but earns its place by explaining why the tool exists.
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?
An output schema exists and annotations cover the safety profile, so the description need not explain return values or read-only behavior. The core intent and trigger condition are stated. Remaining gaps: the expected format of a 'capability' query is unspecified, and no guidance differentiates this from apple_suggest_shortcuts or shortcuts_list_shortcuts. Adequate but not 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?
With 0% schema description coverage, the description must compensate for the schema's bare parameter titles. 'Requested capability' adds real meaning to the query parameter, indicating it should be a natural-language capability description. The limit parameter remains undocumented, though its default and name make its role mostly self-evident. Compensation is partial, not complete.
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+resource ('List likely shortcuts') and a clear purpose: using Shortcuts as a bridge when native coverage is missing. It inherently differentiates from generic tools like shortcuts_list_shortcuts, but it does not explicitly distinguish itself from the closely named sibling apple_suggest_shortcuts, so it falls just short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when native coverage is missing' provides an explicit condition for using this tool, giving the agent a trigger context. However, it names no alternatives and gives no when-not-to-use guidance, so routing between this and apple_suggest_shortcuts or shortcuts_list_shortcuts is left to inference.
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 that the tool does not send anything but returns a recommended mail or messages target, which clarifies its non-mutating, advisory behavior. This goes beyond the annotations in explaining the tool's purpose.
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 sentence that front-loads the core functionality and avoids filler. It is concise and readable, though it slightly crams multiple actions into one sentence without clear section separation. No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main use case and notes the tool is a pre-send step, but it leaves ambiguity around how 'preferred_channel' influences the result and what happens when resolution fails or a channel is unavailable. The output schema exists and may fill these gaps, but its contents are not shown in the provided context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the explanatory burden. It mentions 'recipient' and 'channels' but gives no additional meaning for the optional 'preferred_channel' parameter, such as whether it overrides the recommendation or merely biases it. There are no enums or examples to help an agent understand the expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses concrete verbs ('Resolve', 'evaluate', 'return') and names the resource ('recipient', 'channels'), clearly indicating this tool prepares communication by resolving a contact and recommending a channel. It distinguishes itself from sending and previewing, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before sending' implies a clear temporal position in the workflow, suggesting this tool is a pre-send step. However, it does not explicitly state when to choose this tool over alternatives like apple_preview_communication or apple_send_communication, nor does it mention anything about skipping it.
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 covered. The description adds 'current Apple data surfaces' and the fallback role, which provides some context but remains vague about what data surfaces are used or how suggestions are produced. 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?
Two short sentences with the core purpose front-loaded and the fallback context stated efficiently. Minor redundancy with the title ('Apple Suggest Contacts') keeps it from being a 5.
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 presence of an output schema covers return values, and annotations cover safety, so the description only needs to explain invocation context. It does that reasonably for a fallback tool, but it leaves parameter semantics and 'current Apple data surfaces' unexplained, making it minimally adequate rather than 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?
Schema description coverage is 0%, and the description does not explain the query or limit parameters at all. While the parameter names are somewhat self-explanatory, the description adds no meaning beyond the schema's type/default information, which is insufficient at this coverage level.
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 names a specific verb ('Suggest') and resource ('Contacts'), and the completion-fallback phrase clarifies this is for autocomplete-style lookups. It does not explicitly contrast with contacts_search_contacts, so it stops short of full sibling differentiation.
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 clearly states the intended use case: completion fallback for clients without MCP completion support. This gives an explicit trigger condition, though it does not mention 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?
Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds useful behavioral context by framing the tool as a fallback completion surface and noting dependence on 'current Apple data surfaces,' which implies results may reflect current system state.
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 short, with only two sentences and no filler. The second sentence adds a meaningful usage context, though the first sentence is somewhat repetitive of the tool title.
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 tool with an output schema and strong annotations, the description covers purpose and fallback role. However, it lacks parameter semantics and explicit sibling differentiation, leaving some context for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no guidance on 'query' or 'limit.' While parameter names and defaults are visible, the description does not explain matching behavior, the string variant of limit, or how query interacts with suggestions.
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 ('suggest') and resource ('mailboxes'), and adds that it uses 'current Apple data surfaces.' It stops short of explicitly distinguishing itself from sibling tools like mail_list_mailboxes, though the 'completion fallback' phrase provides some differentiation.
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?
It clearly identifies a use case: 'completion fallback for clients without MCP completion support.' However, it does not mention when to prefer alternatives such as mail_list_mailboxes or other suggest_* tools, nor does it give exclusion 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 readOnlyHint=true and idempotentHint=true, establishing the safety profile. The description adds only the fallback context and 'current Apple data surfaces' phrase, without detailing matching behavior, result ordering, or how the suggestion list is produced. It does not contradict the annotations and adds some context beyond them.
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 two sentences long, front-loads the core operation, and contains no filler. The first sentence repeats the tool title, but the second sentence earns its place by clarifying the fallback use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With read-only and idempotent annotations, an output schema, and no required parameters, the tool is relatively simple to invoke safely. However, the description leaves the semantics of query and limit unclear and does not explain what 'current Apple data surfaces' means, making the definition adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions neither 'limit' nor 'query'. The parameter names are conventional enough for light inference, but the description adds no meaning beyond the schema and fails to compensate for the complete absence of parameter documentation.
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 operation — suggesting reminder lists — and adds the clarifying context that it is a completion fallback for clients without MCP completion support. This separates it from list-style tools like reminders_list_lists, though 'using the current Apple data surfaces' is somewhat vague.
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 explicitly frames when to use the tool: as a completion fallback for clients without MCP completion support. It does not name specific sibling alternatives or exclusions, but the fallback framing gives a clear usage cue that is not present in the schema or annotations.
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 are sparse (no readOnly, no idempotent, no destructive hints). The description does disclose one useful behavioral trait: the tool will fall back to the configured default folder when folder_id is absent. But it doesn't disclose what happens if no default folder is configured, whether this operation is reversible, or what the created note object contains. With no output schema details in the description and an empty annotations set, there is room for more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. The most important behavior, default-folder fallback, is front-loaded in the first clause. 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?
The tool sits among many create/preview variants (apple_create_note_with_defaults, apple_preview_create_note_with_defaults, notes_create_note). The description clarifies only the default-folder aspect; it doesn't explain body format precedence, how tags are applied, or whether the preview variants should be used first. Given the rich sibling context and the 0% schema coverage, the definition could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema itself gives no parameter documentation. The description adds meaning only to folder_id, explaining that it can be omitted to use the default folder. It does not clarify the distinction between body_html and body_text (which is body preferred), the format of tags, or whether title is used as the note title. The description compensates for exactly one parameter and leaves the other four without semantic guidance.
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+resource ('Create a note') and adds a meaningful differentiator: it uses the configured default notes folder when folder_id is omitted. This distinguishes it from the sibling notes_create_note, suggesting this variant defaults the folder. However, it doesn't explicitly name the sibling alternative, so it doesn't fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage condition: use this tool to create a note when you want the default folder, or when no folder_id is provided. It gives no explicit guidance about when to choose this over notes_create_note, apple_preview_create_note_with_defaults, or apple_create_reminder_with_defaults. The 'when folder_id is omitted' phrasing is clear context but there are no when-not-to-use statements or named alternatives.
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 read-only and idempotent behavior, and the description adds the fallback rendering context. It doesn't disclose much beyond that, but it doesn't contradict the annotations either. The output schema covers return-shape expectations.
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, no filler, and the operative meaning is front-loaded. All words contribute to defining its fallback 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?
For a simple, read-only, idempotent tool with an output schema, the description is minimally viable. It fails to explain how the prompt name is selected, how `argumens_json` affects rendering, or the relation to apple_list_prompts, so an agent is left to infer some call semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no guidance on what `name` or `argumens_json` should contain. The names are somewhat self-explanatory, and 'rendering' hints that `argumens_json` may feed the prompt, but the description does not compensate for the missing schema descriptions.
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 operation ('prompt rendering') and target resource ('prompt'), and adds the fallback context of tool-only clients. It doesn't explicitly distinguish this from sibling tools like apple_list_prompts, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates when to use the tool: as a fallback for clients that only support tools, implying a narrow, compatibility-oriented use case. It doesn't name alternatives or say when not to use it, but the context is clear enough.
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 read-only and idempotent hints are already covered by annotations, but the description adds context beyond them by stating that the tool fails closed when the Maps helper is unavailable. This is a useful behavioral trait that affects invocation expectations. 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?
One sentence with no filler: it front-loads the core action, specifies the backend, and captures the critical failure behavior. Every element contributes to invocation understanding.
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 search tool, the description plus annotations and output schema cover the basics: read-only, idempotent, fail-closed search with query and optional limit. However, it lacks explicit alternatives guidance and does not clarify what fail closed means in practice (error vs. empty result), leaving some invocation ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description provides no parameter-level meaning beyond the schema's property names and default. The query and limit parameters are simple, but the description does not clarify accepted formats, semantics of limit, or any constraints. With low schema coverage, the description was expected to compensate and does not.
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: search places through Apple Maps. It also adds a meaningful distinguishing behavior—fail closed if the Maps helper is unavailable. However, it does not explicitly differentiate itself from the sibling maps_search_places, so it falls just short of full clarity.
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 fail-closed behavior implies this is the version to use when availability guarantees matter, which is a useful usage signal. But the description does not explicitly state when to choose this tool over maps_search_places or other alternatives. Usage guidance is therefore implied rather than fully specified.
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 readOnlyHint and idempotentHint annotations already establish that no side effects occur and repeated calls are safe. The description's 'Preview... before creating' matches those annotations and adds the context that the tool covers both a reminder and a note, but it doesn't disclose additional behavior such as what inputs are validated or how the preview is returned.
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 that leads with the verb and front-loads the preview purpose before the 'before creating' caveat. No filler or redundant restatement of the tool name.
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?
This is a moderate-complexity tool with six parameters and no parameter descriptions, so the one-line description is enough for selection but not fully enough for correct invocation without relying on the schema's self-explanatory titles. The output schema and readOnly annotations fill some gaps, but the lack of parameter guidance and explicit alternatives leaves the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain the parameters, but it only indirectly maps 'email' to message_id and 'reminder and note' to the create/title flags. It does not clarify the role of due_date, the default true/false behavior of create_reminder/create_note, or which titles are used.
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 action ('Preview') and the resource/transformation ('an email into a reminder and note'), and the phrase 'before creating either item' distinguishes it from actual creation tools. It is clear, though it doesn't explicitly name the sibling preview tools it competes with.
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 'before creating either item' gives a clear condition for when to call the tool, positioning it as a dry-run/preview step. It does not explicitly name alternatives such as apple_capture_follow_up_from_mail or the single-item preview tools, nor state 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?
With annotations already marking idempotence and destructiveness, the description adds a concrete behavioral trait: it prompts the user when recipient or text is absent. This tells an agent that omitted parameters trigger an interactive request rather than a silent failure. It does not overpromise side effects or contradict openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the primary action and appends the key conditional behavior. No filler or repeated schema info.
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 definition covers the core flow of an interactive send for a two-parameter tool and an output schema exists. However, it omits when to choose this tool over non-interactive senders and does not explain what happens after the interactive prompt, so the 0% schema coverage is not fully compensated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries more weight. It maps directly to both parameters ('recipient or text') and clarifies that omitting them is acceptable because the tool will ask. However, it does not define expected recipient formats (name, phone, email) or provide text constraints, leaving significant semantics to the agent.
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?
Description uses a clear verb-resource pair ('Send an Apple Messages message') and adds the interactive behavior ('asking for missing recipient or text when needed'). It is distinct from a plain send, though it does not name a sibling tool or explicitly contrast with messages_send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to prefer this interactive variant over messages_send_message or apple_send_communication. The 'when needed' clause describes prompt behavior, not tool-selection context, and no alternatives 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.
- 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 covered. The description adds that suggestions come from 'current Apple data surfaces' and that the tool serves as a fallback, which is light but non-contradictory context. No deeper behavioral details such as rate limits or result-scoping behavior 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?
Two short sentences, front-loaded with the core purpose and followed by the fallback context. There is no filler or redundant restatement of the tool name.
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, has an output schema, and benefits from read-only/idempotent annotations, so it does not need extensive documentation. However, 'current Apple data surfaces' is vague and the description does not clarify what kinds of files are suggested, how query affects results, or how the fallback behavior differs from normal MCP completion. The basics are present, but the agent is left inferring some invocation semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining limit and query. It does not mention either parameter at all, leaving the agent to infer their meaning from names and defaults. This is a notable gap for a low-coverage schema.
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 ('suggest') and resource ('files') and adds the source ('current Apple data surfaces'), which makes the tool's core purpose identifiable. It also notes this is a completion fallback, clarifying how the tool is meant to be used. It does not explicitly contrast with other apple_suggest_* siblings, but 'files' provides enough differentiation.
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: this is a completion fallback for clients without MCP completion support, so an agent knows when this tool is appropriate. It does not mention explicit exclusions or alternatives, but the stated fallback role is genuinely useful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile, so the bar for the description is lower. It adds mild behavioral context by framing results as derived from 'current Apple data surfaces' (live/computed, not static) and by positioning the tool as a completion fallback. It does not address behavior for empty queries, ranking, or no-suggestion cases, but with annotations present this is an acceptable contribution.
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 totaling roughly 24 words, with the action front-loaded in the first sentence and the usage context in the second. No fluff, no repetition of the title, no filler—every clause 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?
The output schema covers return values, annotations cover the safety profile, and the description covers purpose plus a usage trigger—adequate for a simple 2-optional-parameter, read-only tool. The clear remaining gap is the parameter contract: an agent must guess what query and limit mean. It is viable but leaves meaningful information to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no direct meaning for either parameter: 'limit' (an oddly typed integer-or-string with default 25) and 'query' (nullable string) are never explained. The 'completion fallback' framing weakly implies query is a completion prefix and limit caps results, but that is inference, not documentation. With zero schema coverage, the description was obligated to compensate and largely did not.
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 action, 'Suggest Shortcuts', clearly identifying verb and resource. The completion-fallback note gives it a distinct role, and 'using the current Apple data surfaces' signals live system context. However, 'current Apple data surfaces' is vague jargon, and it does not explicitly differentiate from siblings like shortcuts_list_shortcuts or apple_list_shortcuts_for_capability.
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 second sentence is an explicit trigger condition: 'This is a completion fallback for clients without MCP completion support,' telling the agent precisely when this tool is the right choice. It falls short of a 5 because it names no alternatives and gives no when-not-to-use guidance, despite a large apple_suggest_* sibling family where such routing would help.
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 well covered. The description adds context about the 'delegated Apple domain', which suggests permissions or a delegation model, but it does not disclose what happens when no accounts exist, whether the list is empty, or whether account types (iCloud, Exchange, etc.) are returned. With annotations covering safety, the added behavioral context is moderate.
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 sentence, compact and front-loaded with the tool name and domain. The trailing 'exposed through Apple-Tools-MCP' is somewhat redundant boilerplate, but it does not detract heavily from readability or scannability.
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 zero-parameter, read-only listing tool, this is minimally viable but lacks useful context: it does not explain what 'accounts' means, how the returned list relates to notes_list_folders or notes_list_notes, or whether the output is a flat list or a structured hierarchy. The presence of an output schema reduces the need to describe return values, but the relationship to sibling tools remains unexplained.
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 document. Schema description coverage is 100%, meaning the schema already fully communicates the invocation contract. The description correctly implies that only an account list is returned. A 4 is appropriate since there is no parameter information deficit.
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 and resource: the tool lists accounts for the delegated Apple Notes domain. It distinguishes itself from sibling list tools like notes_list_folders and notes_list_notes by naming the resource ('accounts'). The generic 'exposed through Apple-Tools-MCP' phrasing adds some noise, but the core purpose is clear.
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 for enumerating available Notes accounts within a delegated domain, but it does not explicitly state when to use it versus siblings such as notes_list_folders or notes_list_notes. No exclusionary guidance is provided, and there is no mention of whether this should be called before other Notes operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to justify safety. It does add useful context by naming the aggregated sources, but it does not disclose potential permission requirements, failure behavior, or what happens when sources are empty. Given the annotations, this is acceptable 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, front-loaded sentence that states the action, the artifact, and the data sources with no filler or repetition. It maximizes information density while remaining immediately readable.
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 read-only and idempotent annotations, plus the presence of an output schema, the description is reasonably complete for a low-risk generation tool. However, the complete absence of parameter explanations and any usage guidance leaves notable gaps for an agent needing to customize the briefing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning of days, mail_limit, or mail_query. An agent can guess from parameter names and defaults, but the description adds no clarification about how these parameters affect the briefing period, mail filtering, or result volume.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Generate'), a specific resource ('weekly Apple briefing'), and the data sources (upcoming events, reminders, Mail highlights). It also distinguishes itself from the sibling apple_generate_daily_briefing through the explicit 'weekly' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for creating weekly briefings but does not explicitly state when to prefer it over alternatives, such as apple_generate_daily_briefing. There are no when-not-to-use conditions or named alternative tools, so the guidance is only implicit.
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 aligns with those by framing the tool as an explanation rather than a mutation. It adds useful context about being scoped to an Apple domain on macOS, but it does not disclose whether the tool inspects current permissions or simply returns instructions. 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 is a single, front-loaded sentence with no filler. 'Explain how to grant' appears immediately and the platform and scoping are included without extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only guide tool with an output schema and safe annotations, the description is mostly sufficient. However, the lack of any enumeration or examples for the 'domain' parameter—combined with 0% schema coverage—leaves the agent to infer acceptable values, which is a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is a single optional 'domain' parameter with a default of 'all.' The description adds that domain refers to an Apple domain, but it does not enumerate valid domain values, provide examples, or clarify how 'all' behaves. Because the schema provides no descriptions, the description carries the burden and only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action—'Explain how to grant'—and a specific resource—'Apple permissions needed by a given Apple domain on macOS.' Its informational nature distinguishes it from sibling tools like apple_update_preferences and apple_recheck_permissions, which actually modify or recheck permissions.
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 use when a user needs guidance on granting permissions for a given Apple domain, but it does not explicitly state when to use this tool versus alternatives. No exclusions, prerequisites, or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description reinforces the preview behavior and adds that it uses the configured default reminder list, but it doesn't disclose additional edge behavior; this is acceptable 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?
One short, front-loaded sentence that conveys both the preview nature and the default-list context. No filler or repetition of obvious schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for selecting the tool and understanding that it is a read-only preview, and the output schema covers return values. However, with five parameters and zero schema descriptions, the input semantics are not fully specified, leaving a meaningful gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of title, notes, list_id, due_date, or priority. The agent must guess date formats and priority semantics from parameter names alone, so the description fails to compensate for the missing schema 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?
It states a specific verb ('Preview') and a specific resource ('how Apple-Tools will create a reminder'). The 'Preview' wording clearly separates this from the actual creation sibling apple_create_reminder_with_defaults, so the operation 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 'Preview' framing implies this is the dry-run tool to use before an actual creation, but the description never explicitly names the alternative creation tool or states when not to use it. The intended usage is inferable rather than 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, so the safety profile is covered. The description adds only the vague 'current Apple data surfaces' context and the completion-fallback role, which is useful but not a substantive behavioral disclosure beyond what annotations provide.
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 with no wasted words. The purpose and usage context are front-loaded, and the completion-fallback note 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?
The description is adequate for a simple suggestion tool with read-only annotations and an output schema, but it leaves parameter semantics entirely uncovered and does not clarify the shape of the expected suggestion behavior. An agent could invoke it for calendar completion, but not with full confidence about query/limit handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain 'limit' and 'query', but it does not mention either parameter. The tool name implies calendar suggestions, but no meaning is added about how query filters or how limit affects results.
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 ('Suggest') and resource ('Calendars'), and adds the distinctive context that it is a completion fallback for clients without MCP completion support. This clearly separates it from the many sibling suggest_* tools by naming the calendar resource and its intended role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'completion fallback for clients without MCP completion support' explicitly tells the agent when this tool should be used. It does not name explicit alternatives or list exclusions, but the use case is clear enough to route selection correctly.
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, and the description's 'Report' is consistent with that safety profile. The description does add one behavioral trait beyond annotations: the output is a cross-domain aggregation rather than a per-domain detail view. It does not disclose what 'health' encompasses or whether the aggregate depends on permissions across multiple domains, but with annotations carrying the safety burden that 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?
A single sentence of roughly a dozen words that front-loads the verb 'Report' and wastes no words. Every term ('aggregated', 'across', 'MCP domains') carries meaning that helps disambiguate the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool with an output schema present, the description is nearly complete — return values are documented by the output schema, so the description need not explain them. The main gaps are that 'health' is never defined and the set of aggregated domains is not enumerated, which an agent might need to decide between this and the *_health siblings confidently.
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 input schema trivially covers everything and there is nothing parameter-related for the description to add. Per the rubric, 0 params earns a baseline of 4.
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 and resource: 'Report aggregated health across the unified Apple ecosystem MCP domains.' The word 'aggregated' plus 'across...domains' distinguishes it from the per-domain *_health siblings in the tool list (mail_health, calendar_health, reminders_health, etc.). The phrase 'unified Apple ecosystem MCP domains' is somewhat vague about which domains are covered, which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied rather than stated: an aggregate health overview can be inferred from 'aggregated...across domains', but the description never explicitly says when to use this instead of the per-domain *_health tools. No exclusions or alternative routing are provided, so an agent must infer that domain-specific questions belong to siblings like mail_health or system_health.
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 that this is non-idempotent and non-destructive, and the description adds the meaningful conditional that undo only works when underlying MCPs support it. It stops short of disclosing what happens otherwise — whether the tool returns an error, silently no-ops, or partially reverses — which is a notable gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the core verb and resource front-loaded, and the reliability qualifier justifies its length because it prevents misuse. There is no wasted wording.
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 single-parameter tool with an output schema, the definition is broadly adequate, but two gaps remain: the source of action_id (the sibling apple_list_recent_actions is clearly the companion but is never referenced) and the ambiguous meaning of 'recent' (order of undoability, time window). An agent could select the tool but might struggle to invoke it correctly.
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?
With 0% schema description coverage, the description must carry the parameter meaning. 'A recent Apple-Tools action' does map naturally to action_id, but it never tells the agent where to obtain a valid ID (e.g., from apple_list_recent_actions) or what form the ID takes. The compensation is partial, not complete.
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 clear, specific action ('Undo') with a well-defined resource ('a recent Apple-Tools action'), and the qualifier about reliable reversal adds real meaning rather than vagueness. No sibling tool performs this function, so differentiation is unnecessary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when the underlying standalone MCPs support a reliable reversal' gives a genuine precondition for use, which is useful. However, it provides no exclusions, no guidance on how to determine whether a reversal is reliably supported, and no alternative to fall back on when it is not.
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 provide readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds useful context about what is searched (tool catalog) and the supported match types, but it does not disclose output verbosity, pagination, or whether domain_tags can also be passed through query; this is consistent with 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?
One sentence, front-loaded with the action and object, zero filler. Every word contributes to the agent's understanding of what the tool searches and how.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and an output schema present, the description does not need to explain return values. Still, it is minimal: it does not clarify the relationship between query and domain_tags, nor the meaning of mode beyond its default. It is adequate for a simple search tool but leaves some invocation nuances implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add real meaning by explaining that search can match aliases and domain tags in addition to keywords, which clarifies the query parameter's behavior. However, it leaves mode and limit undcribed; their defaults mitigate the gap but do not fully document valid options.
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 ('Search') and a precise resource ('this server's tool catalog'), plus the three matching dimensions: keyword, alias, and domain tag. This clearly distinguishes it from sibling data-search tools like mail_search_messages, files_search_files, and contacts_search_contacts.
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 a clear use case: discovering tools in the server-side catalog by keyword, alias, or domain. However, it never explicitly states when not to use it or points to an alternative such as get_tool_info for exact tool metadata lookups, so routing between siblings remains partially inferred.
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 signal non-destructive, non-idempotent behavior. The description adds the useful decision logic: use the preferred archive mailbox if a preference exists, otherwise auto-detect. It doesn't cover failure modes or side effects on the original message, but this is reasonable given 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?
A single sentence with no filler, front-loaded with the core action and followed by the fallback behavior. Every clause adds meaningful information.
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 core behavior is described, but the description omits how optional archive_account and archive_mailbox interact with the preferred mailbox or auto-detection logic. This matters for correctly invoking the tool in specific-target requests. Output schema and annotations mitigate some gaps, but the omission is noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain message_id, archive_account, or archive_mailbox. The auto-detect clause gives minimal context to the archive target parameters, but the required message_id is entirely unexplained.
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 ('Move') and resource ('a message'), and clearly defines the target ('preferred archive mailbox' or auto-detected). This distinguishes it from generic mail_move_message and thread-level mail_archive_thread without needing to name them.
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 is implied: archive a single message to the preferred or auto-detected archive mailbox. However, it provides no explicit when/when-not guidance or alternatives, so the agent must infer when to choose this over sibling tools like mail_archive_thread or mail_move_message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already marking the tool readOnly and idempotent, the description adds a meaningful behavioral branch: it can return duplicate groups instead of a resolved contact. No contradiction with annotations; 'resolve' and 'return' fit readOnly behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the main purpose and then adds the important duplicate behavior. No filler or repetition of schema/annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema and safety annotations, the description covers the main purpose and the key branching behavior. The main missing context is query semantics, already penalized under parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not compensate: the single 'query' parameter is never explained in terms of accepted format (name, email, phone, partial match). The agent is left to infer that query somehow identifies a contact.
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 action ('resolve a contact') and resource (contact), plus a condition for stopping when duplicates need cleanup. It is clear but does not explicitly distinguish itself from sibling tools such as apple_find_duplicate_contacts or contacts_resolve_message_recipient.
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?
It gives clear context: use for a person-targeted workflow before acting, and stop if duplicates are found. It does not name alternatives or exclusions, so it stops a point short of the top score.
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 covered. The description adds the useful 'preview / before moving' framing but does not disclose additional behavioral details such as account/mailbox resolution or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence communicates the central purpose and timing with no filler. It earns its place and is immediately scannable.
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, annotated preview tool with an output schema, the description is minimally adequate. It lacks explicit parameter semantics and does not point to apple_archive_message as the actual execution counterpart, which an agent would need for a fully informed call sequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate by explaining message_id, archive_account, and archive_mailbox. It does not: the sentence only implies the tool is about archiving, and leaves the meaning of the optional target parameters ambiguous.
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?
States a specific action (Preview) on a specific resource (archiving a Mail message), and 'before moving it' marks this as the dry-run counterpart to apple_archive_message. The verb and scope make it easy to distinguish from the actual archive and mail_move_message siblings.
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?
'Before moving it' provides a clear temporal context: call this to inspect the archive behavior prior to executing the move. It does not explicitly name apple_archive_message as the follow-up tool or state exclusions, 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 and idempotentHint, and the description's 'Preview ... before sending' is consistent with no side effects. It adds little behavioral context beyond the preview nature, but no contradiction and no need for destructive-operation warnings.
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 with no redundant phrasing. It captures action, resource, timing, and channel context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and read-only annotations cover return values and safety, and the description covers purpose and timing. However, given 6 parameters with 0% schema coverage, the lack of input semantics leaves the definition incomplete for correct invocation using optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter-level guidance. Required fields like recipient and message are self-explanatory, but optional fields such as preferred_channel, from_account, and attachments lack semantics or allowed values, so an agent cannot reliably invoke with them.
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 ('Preview') and resource ('communication') and states the scope ('route ... before sending it through Messages or Mail'). This makes it clearly distinct from actual send/prepare siblings.
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?
It gives a clear usage context: use this when you need to see routing before delivering via Messages or Mail. It does not explicitly name alternatives or state when not to use, but the 'before sending' phrasing effectively separates it from send actions.
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 description does not need to restate that this is a safe read-only operation. It adds semantic context by explaining that attendee state is summarized for collaboration verification, but it does not disclose what dimensions of attendee state are covered or any operational constraints such as calendar access 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 sentence with no unnecessary words. It front-loads the action and the intended outcome, making it easy for an agent to quickly understand the tool's role.
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-only summary tool with an output schema and safety annotations, the description covers the core contract well. It could be more specific about what 'attendee state' means or how 'shared' is determined, but the output schema likely fills in the return structure and the intended use is clear.
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 provides zero description for the only parameter, event_id, and the tool description never mentions event_id or explains how to obtain it. The phrase 'shared calendar event' indirectly implies that event_id refers to a shared event, but that is minimal compensation for 0% 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?
The description uses a specific verb ('summarize') and resource ('attendee state for a shared calendar event'), and pairs it with a clear goal: allowing agents to verify collaboration and participation. This semantically distinguishes it from siblings like calendar_get_event and calendar_list_events, which focus on event details rather than attendee collaboration state.
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 explicitly frames when the tool should be used: to verify collaboration and participation for a shared calendar event. It does not name alternatives or state when not to use it, such as 'for raw event details, use calendar_get_event', but the intended use case is clear enough.
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 covered. The description adds only the 'fallback for tools-only clients' framing, which is more contextual than behavioral; it does not describe output shape or side-effect-free behavior beyond what annotations 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?
One sentence with no filler. It states the purpose and the triggering condition compactly, and every word adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with an output schema, the description is nearly sufficient. It could explicitly mention that it returns prompt identifiers or that apple_get_prompt should be used for individual prompt retrieval, but nothing critical is missing.
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 schema coverage is 100%, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter documentation is needed.
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 identifies a specific resource (prompts) and a clear activity (discovery/list), and adds the 'fallback' qualifier that explains its niche. It does not explicitly contrast itself with the sibling apple_get_prompt, but the list-vs-get distinction is legible from the tool names.
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 a clear usage context: it is a fallback discovery mechanism for clients that only support tools. It does not list explicit exclusions or name alternative tools, but the condition for use is stated directly and concisely.
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 read-only safety profile is covered by structured data rather than the description. The description adds useful context that Apple-Tools durably records assistant actions, but it does not disclose ordering, how 'recent' is defined, what the default limit does, or anything about pagination. It adds some value without contradicting 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?
A single front-loaded sentence with zero filler: verb, resource, and purpose in one line. It does not restate the title or redundantly repeat information already present in the schema or annotations.
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 low-complexity tool with one optional parameter, an output schema that covers return values, and annotations that cover safety, the description covers purpose and intended use well. Minor gaps remain: the meaning of limit, the recency window, and explicit guidance on when to use this versus apple_undo_action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning, yet it never mentions the limit parameter. The name 'limit' is somewhat self-explanatory and the default of 10 appears in the schema, but the unusual integer-or-string union type and its accepted formats are entirely unexplained. The description fails to compensate for the missing schema 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?
States a specific verb ('List') plus a precise resource ('recent assistant actions recorded by Apple-Tools'), and it names the intended purpose ('for audit and undo workflows'). This clearly distinguishes it from the sibling apple_undo_action, which executes an undo rather than enumerating the log, and from other listing tools by scoping to assistant actions.
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 'for audit and undo workflows' gives clear context for when the tool should be called — it is the read-side log that supports undoing prior actions. However, it does not explicitly state when not to use it or name the alternative (apple_undo_action) that performs the actual undo endpoint.
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 mark destructiveHint=false, and the description adds meaningful behavioral context: the operation goes through the Apple Files app and returns iCloud-aware metadata, implying a visible open action with a specialized result. It does not contradict the annotations, though it could mention whether it launches a GUI or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the action and resource and adds scope plus output context without filler. Every word contributes to understanding when and how to use the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema and safety annotations, the description covers the core action and the iCloud-specific purpose. It lacks explicit usage boundaries against sibling file tools, but the essential calling context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for explaining the 'path' parameter. It does usefully clarify that the path can refer to either a file or a folder, but it does not specify path format, whether it should be absolute or iCloud-relative, or any constraints, so some semantics are left to inference.
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 ('Open'), names the exact resource ('a file or folder through Apple Files'), and specifies the distinguishing output ('iCloud-aware path metadata'). This clearly differentiates it from sibling tools such as files_open_path or apple_reveal_in_finder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'through Apple Files' implies when this tool is appropriate: opening in the Files app and needing iCloud-aware metadata. However, the description does not explicitly name alternative tools or state when not to use it, leaving sibling differentiation mostly to 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 and idempotentHint, so the description does not need to restate safety. It adds context about what the call returns (schema, examples, metadata), but it does not disclose any additional behavioral traits such as potential size of responses, error behavior, or whether it requires special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one tightly written sentence with no filler. It front-loads the core purpose and includes the key output components without wasting words on trivia.
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 introspective tool with an output schema and read-only/idempotent annotations, the description is largely complete. The only notable gap is the absence of any guidance on how this tool relates to search_tools or other discovery mechanisms, but an agent can still call it correctly based on the provided information.
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 0% schema description coverage, the description carries a heavier burden, and it does partially compensate: 'for one tool' clarifies the name parameter, while 'full schema, examples, and metadata' maps directly to include_schema and include_examples. It does not give detailed semantics for each flag or mention defaults, but the meaning is reasonably inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Load'), a precise resource ('full schema, examples, and metadata for one tool'), and a clear scope ('from this server'). It clearly distinguishes this introspection tool from the many domain-action siblings by emphasizing that it returns schema/examples/metadata rather than performing a real-world 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 clearly implies the tool is for fetching tool details, but it never explicitly says when to use it versus alternatives such as search_tools or other introspection helpers. There is no guidance about when not to use it or which sibling might be a better choice for tool discovery.
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 only indicate a non-idempotent, non-destructive action. The description adds an important behavioral trait not visible in the schema: reliance on a configured default reminder list when list_id is omitted. It also clarifies that the operation is a create/write. 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?
A single front-loaded sentence states the core behavior and the scoping condition. No filler words; every element 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 small create tool with an output schema and mostly self-evident parameters, the description covers the central decision (when the default list applies) and the action. It doesn't describe how to configure the default list or mention the preview sibling, but these are peripheral for direct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to shoulder the explanatory burden. It provides semantic meaning only for list_id (omission triggers default list). It does not explain title, notes, due_date, or priority values/formats, leaving the agent to guess from parameter names and default values.
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 names a specific action ('Create a reminder') and a specific resource, then adds the distinctive condition ('using the configured default reminder list when list_id is omitted'). This separates it from the generic reminders_create_reminder and other apple_*_with_defaults siblings without requiring schema inspection.
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 'when list_id is omitted' gives a clear usage condition: this tool is for creating reminders without a specific list. It does not explicitly name the alternative (e.g., reminders_create_reminder) for cases where a list_id is supplied, so the exclusion is implied rather than 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?
The annotations already declare readOnlyHint and idempotentHint, so the safe, non-mutating nature is established. The description adds context about what the snapshot includes (Focus, frontmost app, battery state) but does not disclose additional behavioral details such as permissions or latency. There is no contradiction with 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, well-structured sentence that front-loads the action and resource, then lists the relevant fields. There is 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?
Given the tool has no parameters, a read-only/idempotent annotation profile, and an output schema provided separately, the description is complete enough for an agent to select and invoke it. It clearly communicates the scope of the returned context without needing additional explanation.
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%, so there are no parameter semantics for the description to clarify. The baseline of 4 applies, and the description does not need to compensate for any parameter documentation gaps.
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 ('Return'), a specific resource ('Apple system context snapshot'), and enumerates the key fields included (Focus, frontmost app, battery state). It distinguishes itself from sibling tools like apple_get_focus_status and system_get_battery by presenting itself as a richer, Apple-specific aggregate snapshot.
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 is implied: call this tool when a combined Apple system context snapshot is needed. However, it does not explicitly say when to prefer this over individual sibling tools like system_get_context_snapshot, system_get_frontmost_app, or system_get_battery, nor does it state 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?
Beyond the readOnlyHint annotation, the description discloses a useful non-obvious behavior: it notifies the client that Apple resources changed. It does not mention authorization needs or transformation of resources, but for a zero-parameter recheck tool this is adequate. The notification wording is not a clear contradiction of readOnlyHint because the tool still appears not to mutate Apple state.
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 with no filler: it states the action, the trigger, and the notable side effect in under 20 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with an output schema, the description covers when to invoke it and what to expect behaviorally. It could be slightly more explicit about what 'Apple domain health' includes, but the essential invocation context is present.
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 already shows an empty object, so there is nothing for the description to add. The 0-parameter baseline applies.
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 a clear action ('Recheck Apple domain health') and a trigger ('after the user changes macOS permissions'), so an agent can identify what the tool does. It does not explicitly differentiate from sibling health-check tools, but the post-permission-change context makes it distinct.
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 'after the user changes macOS permissions' gives an explicit when-to-use context. It does not state when not to use it or name alternatives like apple_health or apple_get_preferences, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, which cover the safety profile. The description adds the useful context that the values are persisted defaults and routing preferences, but it does not disclose additional behavioral details such as error conditions or what 'routing preferences' concretely affects. This is sufficient for such a simple getter, but not especially 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 sentence, front-loads the action verb, and contains no filler or redundant information. Every word contributes to understanding the tool's purpose.
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 no-argument, read-only, idempotent getter with an output schema, the description is complete enough for an agent to invoke it correctly. No additional behavior, prerequisites, or edge-case guidance is necessary.
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 100% schema coverage, so the input schema is already complete. Per the baseline for zero-parameter tools, no additional parameter explanation is 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 states a specific verb ('Read') and a specific resource ('persisted Apple-Tools assistant defaults and routing preferences'), making the tool's purpose immediately clear. It is easily distinguished from sibling apple_update_preferences, which implies mutation.
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 makes clear that this tool is for reading saved preferences, so an agent can infer when to use it. It does not explicitly name alternatives or state conditions for when not to use it, but the read/update split is strongly implied by the sibling names.
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/JonathanRReed/Apple-MCPs'
If you have feedback or need assistance with the MCP directory API, please join our Discord server