Apple MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct macOS domain or application (e.g., brightness, Music, Safari, Calendar). Despite some surface-level overlap (e.g., apple_music vs apple_spotify, apple_safari vs apple_chrome), the tool names and action lists clearly separate their purposes, leaving no real ambiguity.
Naming Consistency5/5
All tool names follow the exact pattern 'apple_<domain>', using lowercase snake_case throughout (e.g., apple_brightness, apple_sysinfo, apple_textedit). This is perfectly consistent and predictable, making it easy for an agent to infer the tool for a given task.
Tool Count2/5
With 31 tools, this server exceeds the 25+ threshold considered 'too many' in the calibration. Even though each tool represents a distinct feature area, the sheer number creates a heavy surface that may overwhelm agents and complicate selection.
Completeness4/5
The tool set covers a wide range of macOS apps and system functions, including core apps (Mail, Calendar, Notes, Messages), media (Music, Spotify, Podcasts), browsers (Safari, Chrome), and system controls. Minor gaps exist (e.g., no Apple TV, no HomeKit, some apps have limited actions), but these are not critical for common tasks.
Average 3.1/5 across 31 of 31 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that some actions are destructive or require confirmation, nor any side effects. The schema's 'confirm' parameter hints at protected actions, but the description itself adds zero 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it under-specifies a complex multi-action tool. Listing actions duplicates the schema and offers no insight, making it both concise and inadequate. It is not effectively front-loaded with useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 actions, 8 parameters, no annotations, and no output schema, a one-line summary is severely incomplete. It lacks information about return formats, error conditions, prerequisites, or which actions are destructive, leaving the agent without essential context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for every parameter, including detailed action explanations. The description adds no extra meaning beyond listing action names, which is redundant with the schema. Baseline of 3 applies because the schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Control Apple Contacts' which is vague and restates the tool name. It lists action names but gives no explanation of what each does, relying on the schema's enum descriptions. It does not distinguish from sibling tools like apple_mail or apple_calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The action enumeration is a catalog, not usage guidance. There are no conditions, exclusions, or examples to help an agent select this tool 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?
No annotations are provided, so the description carries the full burden, but it only says 'Control' and lists actions. It fails to disclose that actions like send, mark_all_read, and move_to_trash are mutating, nor does it mention the confirm/preview workflow described in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the action list merely duplicates the schema's enum without adding value. It is not bloated, but the redundancy means not every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 10 actions, no annotations, and no output schema, this minimal description is insufficient to convey operation semantics or safety behaviors. The schema's action descriptions compensate for parameter semantics, but the description itself offers no overview of expected results or confirmation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the action enum's descriptions explaining each command. The tool description itself adds no parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Control Apple Mail' and lists all 10 actions, clearly identifying the tool's scope as a mail controller. It distinguishes itself from sibling Apple tools by naming the specific resource, but the actions are only named, not explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use apple_mail versus alternatives like apple_messages or apple_notification. The action list provides no context about suitable use cases 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 provides no behavioral details beyond listing action names. It omits critical caveats such as the confirm parameter for protected/destructive actions, the AppleScript limitations for queue_next and radio, and the fact that set_volume is independent of system volume. With no annotations, the description fails to carry the 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long sentence listing 25 actions. While 'Control Apple Music' is front-loaded, the list is bulky and largely duplicates the schema's action enum values without grouping or summarizing, making it less concise and structured than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 25 actions and no output schema, the description is inadequate. It lacks a high-level overview of behavior, fails to mention the confirm mechanism for destructive actions, and does not describe what the tool returns or any cross-cutting limitations. The schema covers individual actions, but the description does not provide enough context for an agent to safely and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is 100%, so the baseline is 3. The description adds no extra parameter semantics; it merely lists actions without explaining required parameters like 'name', 'level', 'query', or 'confirm'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Control Apple Music' and enumerates all actions, making the resource and scope clear. However, the verb 'control' is vague and no explicit differentiation from sibling music tools like apple_spotify is provided beyond the app 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/5
Does 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 no mentions of exclusions, prerequisites, or context for choosing Apple Music over other music control 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?
With no annotations, the description carries the full burden, but it only says 'Control' and lists actions. It does not disclose whether actions are instantaneous, require permissions, or if the confirm parameter relates to protected/destructive actions. The schema's confirm description hints at such behavior, but the tool description itself omits this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no filler words, and the action list is front-loaded. However, it is so short that it omits important context, which limits its value. Still, for conciseness alone, it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no annotations and no output schema, the description should provide more behavioral context. The presence of a confirm parameter suggests some actions may be protected or destructive, but the description does not explain when confirmation is needed or what the fallback 'preview' behavior entails. The tool is simple, but the description lacks sufficient completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of parameters, including enum descriptions for 'up' and 'down'. The description adds no new semantic information; it merely repeats the enum values. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool controls macOS display brightness, which is a specific verb+resource. It distinguishes from sibling tools like apple_volume or apple_keyboard by focusing on brightness, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of contexts where brightness control is needed or when other tools might be more appropriate. The description merely lists actions without usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists action names and gives no hint that some actions (create_event, delete_event, modify_event) are mutating or that protected actions require confirmation, despite the schema's confirm parameter indicating this. The description fails to convey side effects or safety 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose ('Control Apple Calendar') and concisely enumerates the actions. Every phrase earns its place; there is no redundant filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 7 parameters, no output schema, and no annotations, yet the description provides no information about return values, error handling, or how the actions work together. The sparse description is inadequate for a multi-action tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's action list is redundant with the schema's detailed action enum descriptions and does not add extra meaning to parameters like date, hour, or cal_name. It neither helps nor hinders parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies 'Apple Calendar' as the resource and lists the eight supported actions, making it easy to distinguish from sibling tools for other Apple apps. However, it stops at naming actions without elaborating on the exact operations, so it is clear but not deeply specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like apple_reminders or apple_notes. The description does not mention any exclusions, prerequisites, or preferred use cases. The schema's action descriptions provide per-action context, but the tool-level description lacks 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?
There are no annotations, and the description does not disclose side effects, destructive behavior, or the need for confirmation despite the schema mentioning 'protected/destructive action'. It also doesn't explain what happens to trash, disks, or files during actions like delete or eject.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-organized sentence with a category prefix and action list. It is efficient but reads as a laundry list, with some redundancy against the schema enum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 20 actions and no output schema or annotations, the description omits return formats, side effects, prerequisites, and when to set confirm. It is insufficient for effectively invoking all tool actions safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 8 parameters with 100% coverage, including per-action descriptions in the enum. The description adds no parameter semantics beyond repeating the action list, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Manage Finder' and enumerates 20 actions covering files, folders, trash, wallpaper, disks, and tags. This clearly identifies the Finder resource and distinguishes it from sibling Apple tools, though it is an umbrella statement rather than a single verb+object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided. It merely lists capabilities, leaving the agent to infer that any Finder operation belongs here, but there are no exclusions or compared 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists actions without mentioning important behaviors such as the confirm parameter for protected actions, potential side effects on the system, or whether actions execute immediately. The schema's confirm description is not part of the description field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a list, front-loaded with the core purpose. It is concise and every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description must provide more context. It omits the confirm flow, preview behavior, and any warning about protected/destructive actions, making it incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage, including detailed descriptions for each action enum value and the text, combo, and confirm fields. The description adds no additional parameter semantics beyond listing action names, which are already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as simulating keyboard input, with a specific verb and resource. It lists the available actions, which helps identify the tool's function, though it does not explicitly distinguish it from sibling tools like apple_clipboard or apple_tts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios for using copy/paste actions versus apple_clipboard, or when text input is appropriate. There are no exclusions or conditional use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose safety and side effects. It does not mention that 'send' creates a real-world message, that protected actions require confirmation, or that some actions are read-only. This leaves the agent unaware of important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence with no filler and is front-loaded with the resource name. However, it sacrifices useful context by being so brief, though for conciseness alone it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 actions, 7 parameters, no annotations, no output schema), this description is insufficient. It lacks a high-level overview of behavior, return values, and safety-relevant notes (like confirmation). The schema helps but does not fully compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 7 parameters with detailed descriptions, including per-action explanations in the 'action' enum. The description adds no parameter semantics, but since schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as controlling Apple Messages/iMessage and lists five actions (recent, send, unread, conversation, search), clearly distinguishing it from sibling apple_* tools. However, 'Control' is generic and the description relies on the schema for action definitions, so it is clear but not fully self-contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Sibling tools like apple_facetime or apple_mail are not referenced, so an agent must infer usage from the tool's name and action list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Control Apple Notes' and lists actions. It does not mention that delete is destructive, that confirm is needed for protected actions, or that some actions are read-only, which are critical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the domain and providing an action list. It avoids unrelated detail, though the action list is redundant with the schema's enum, making it slightly less efficient but still an appropriate quick overview.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 7 parameters and 9 actions, no output schema, and no annotations, yet the description is just a summary list. It does not address return values, limitations, prerequisites, or usage scenarios, relying entirely on the schema for details, which leaves the description incomplete for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage, including detailed descriptions for each action enum value. The description adds no additional parameter meaning, merely repeating the action names, so the schema's comprehensive coverage warrants a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Apple Notes and enumerates nine specific actions (list, create, read, search, delete, folders, move, append, count), making its purpose obvious. However, the verb 'Control' is generic and there is no explicit differentiation from sibling tools like apple_reminders, so it doesn't achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any context for selecting among the listed actions. It lacks any 'use case' statements or comparisons with sibling tools, leaving the agent to infer usage from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'Control Apple Reminders' and lists actions. It does not disclose potential side effects, confirmation requirements (despite the schema's confirm parameter), or whether operations are destructive or reversible. This is a significant gap for a tool that includes delete/complete actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences that convey the core purpose and list actions without extraneous text. It is front-loaded with the resource name, though the structure is a simple enumeration rather than a more organized breakdown.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, multiple distinct actions, no output schema), the description is under-specified. It merely lists actions without explaining their behavior, when to use them, or important details like confirmation or list selection. The schema covers parameters, but the description fails to provide a complete overview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all 8 parameters, so the description does not need to add extra parameter semantics. The baseline of 3 applies; the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's domain (Apple Reminders) and lists the supported actions, distinguishing it from sibling tools. While 'Control' is generic, the action list provides specific verbs and resources, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other Apple tools, nor does it explain when to choose specific actions. The action names imply usage, but there is no explicit context, prerequisites, or alternatives 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?
No annotations are provided, so the description carries the full burden for disclosing behavioral traits. It merely lists action names without mentioning side effects, destructive actions (e.g., close_tab, close_window), or permission requirements. The schema does provide some details (e.g., confirm parameter for protected actions), but the description itself adds nothing beyond a bare enumeration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that begins with the core purpose ('Control Safari browser') followed by a complete action list. It is efficient and avoids fluff, though the long action list is slightly redundant with the schema enum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 17 actions and no output schema, the description provides only a high-level overview. The schema compensates with per-action details, so the basics are covered, but the description lacks context on the tool's overall scope (e.g., navigation, tabs, reading list) and how to combine actions. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all four parameters (url, code, action, confirm) having descriptive text. The description adds no additional parameter semantics, but the baseline of 3 is appropriate since the schema already handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool controls the Safari browser and enumerates 17 specific actions, making the purpose unambiguous. However, it does not explicitly distinguish itself from the sibling apple_chrome tool beyond the browser name, so it loses the point for explicit 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use Safari versus other browser tools (e.g., apple_chrome) or when to prefer specific actions. There are no contextual hints, prerequisites, or exclusions; the agent must infer usage entirely from the schema's action descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It fails to mention that actions like restart, shutdown, and logout are destructive or that protected actions require the confirm parameter. While the schema covers this, the description itself provides no safety or side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a long, flat list that is somewhat redundant (categories overlap with actions) but is front-loaded with 'System controls' and covers all actions. It is adequately sized for the large action set but could be more structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is highly complex with 30 actions, and the schema provides detailed action semantics. However, the description lacks output expectations (e.g., what time_machine or audio_output returns) and usage context, making it minimally complete for an agent to safely invoke all actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter meaning beyond listing action names; the schema's per-parameter descriptions already define semantics, so the description provides no additional value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'System controls' and enumerates a comprehensive list of categories and specific actions (sleep, restart, wifi_on, etc.), making it evident that this tool manages system-level settings. It distinguishes from sibling tools by its broad scope, though it lacks an explicit verb phrase like 'controls'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as apple_brightness or apple_volume. The description simply lists available actions without any context for selection, exclusions, or examples of appropriate usage.
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?
With no annotations, the description carries full responsibility for disclosure. It fails to mention that some actions (e.g., set_text, close) may be destructive or require confirmation via the confirm parameter, which is a significant gap in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that lists all actions without filler. It is appropriately sized, though a more structured layout could enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 actions, confirmation mechanism, no annotations or output schema), the description is too minimal. It lacks behavioral context and usage nuances, leaving the schema to carry most of the explanatory burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions for all parameters, including the action enum and confirm. The description adds no additional semantic value beyond what the schema already provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool controls TextEdit and enumerates all supported actions, making its purpose specific and distinct from sibling tools that control other applications. While 'Control' is generic, the action list provides sufficient specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like apple_notes or apple_preview. It does not mention prerequisites, exclusions, or scenarios where a different 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?
No annotations are provided, and the description does not disclose side effects, confirmation requirements, or the protected/destructive action behavior hinted at by the confirm parameter in the schema. It only enumerates actions without explaining their impact or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded with the tool's purpose. Each sentence is useful and earns its place, though it omits contextual details that could contribute to a richer understanding. It is appropriately compact for a lightweight overview.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully covers parameter semantics and the confirm workflow, so the description does not need to repeat those details. However, it lacks context on when to use the tool or how the actions interrelate, making it minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all five parameters, including the action enum, so the description adds no extra meaning beyond restating the action names. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose as 'Text-to-speech on macOS' and lists the specific actions (say, list_voices, stop), making it easy to distinguish from sibling tools that handle other Apple subsystems. While it uses a noun phrase rather than a verb, the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions, prerequisites, or comparison to sibling tools. The action list implies basic usage but does not explicitly state when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists action names, which imply state changes (post, like, retweet), but does not disclose important behavioral traits such as the need for Safari login with JavaScript enabled, the confirmation/preview flow for protected actions, or any side effects. The detailed action descriptions exist in the schema but not in the tool description, so transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one sentence plus a comma-separated list of actions. It is front-loaded with the main purpose. The list of actions is compact and relevant, though a bulleted or semicolon-separated structure could improve readability slightly. Overall, every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 11 distinct actions and 6 parameters, but the description is a brief summary that relies heavily on the schema for action details. While the schema provides extensive information, the description lacks context about when to choose this tool over siblings, the overall workflow (e.g., that it orchestrates Safari), or any caveats. It is minimally viable for an agent that can read the schema, but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description itself does not mention any parameters, but the input schema has 100% coverage with meaningful descriptions for all six parameters (e.g., action, text, num, confirm, auto_send, tweet_url). According to the rubric, high schema coverage sets a baseline of 3, and the description adds no extra parameter semantics, so this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Control X/Twitter via Safari' and lists the specific actions it supports. This gives a specific verb and resource, and the action list clarifies the scope. However, it does not explicitly differentiate itself from the sibling tool 'apple_safari', which may also control Safari actions, so it misses a point for full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no direct guidance on when to use this tool versus alternative tools. It does not mention any prerequisites, exclusions, or specific scenarios where this tool should be preferred. The action descriptions in the schema give some context, but the tool description itself does not offer usage recommendations or comparisons to siblings like apple_safari.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Make FaceTime calls' and does not mention the confirmation requirement for protected actions, the preview behavior when `confirm` is false, potential side effects, or any prerequisites (e.g., FaceTime app installed, user logged in). This is a significant gap for an action that may require confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the main purpose first, then listing the actions. It is extremely concise with no wasted words, and both sentences contribute useful information. This is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and a well-documented schema, the description is minimally viable but lacks key context like the confirmation flow and what happens on execution. There is no output schema, so the agent must infer return behavior. The schema covers parameter details, but the description does not enrich the contextual picture enough to reach a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of all three parameters with descriptions. The tool description adds no extra meaning beyond the schema; it merely restates the action names ('call (video), audio') which map to the enum. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool makes FaceTime calls and enumerates the two actions ('call' for video, 'audio' for audio). It uses a specific verb and resource, making the purpose obvious. However, it does not explicitly differentiate from siblings beyond the unique FaceTime resource, so it earns a 4 rather than 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/5
Does 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 does not mention any exclusions, prerequisites, or sibling tools that might serve similar communication needs (e.g., apple_messages). The usage context is only implied by the tool name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Open Apple Maps' and lists actions, but does not mention any side effects, permissions, or that some actions may be protected/destructive (which the schema's 'confirm' parameter hints at). The description lacks transparency about execution behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The second sentence 'Actions: open, directions' is somewhat redundant given the schema's enum, but it does not add significant clutter. It is appropriately sized, though slightly lacking in explanatory value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is minimal. It fails to explain how the actions relate to parameters, the behavior of the 'confirm' flag, or what happens when executed (e.g., opening an external app). The schema provides parameter details but not the overall operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The tool description adds little beyond the schema, only loosely referencing 'search query' and 'directions', which are already captured in the parameter descriptions. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens Apple Maps with a search query or directions, and lists the two actions. It distinguishes itself from sibling tools by its unique resource (Apple Maps), though the actions 'open' and 'directions' overlap somewhat in their schema descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for Apple Maps actions but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool mentions are present, leaving usage context implicit based on the tool name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only repeats 'Actions: send' from the schema and does not mention side effects, confirmation requirements for protected actions, or any operational details. The tool likely has the side effect of displaying a notification, but this is not explicitly disclosed beyond the verb 'send'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the key purpose. However, 'Actions: send' is redundant given the schema's enum constraint, adding minor noise. Overall, it remains appropriately concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no output schema, and no annotations, yet the description only provides a minimal phrase. It lacks contextual details such as what happens on send, whether the notification is interactive, or when the confirm parameter is necessary. The schema covers parameter syntax, but the description does not give a complete picture of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters (sound, title, action, confirm, message) are already fully described in the input schema. The description adds no new parameter meaning beyond repeating the action enum, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send macOS notifications' clearly identifies the tool's verb (send) and resource (macOS notifications), and it inherently distinguishes this tool from siblings like apple_brightness or apple_tts. Although 'Actions: send' is redundant, it does not obscure the 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions. It simply states the function without contextualizing usage, so the agent receives 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It lists actions but doesn't describe side effects, permissions, or that some actions are protected. The confirm parameter is only explained in the schema, not the description, leaving the agent without better context on consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It states the tool's domain and lists actions immediately, making it easy to scan. Every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (multiple actions, a confirm parameter, no output schema), the description is adequate but minimal. The rich schema compensates for many details, yet the description alone doesn't explain return values or the overall workflow. It's on par with a minimum viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no extra parameter semantics beyond enumerating action names, which are already in the enum. Baseline of 3 is appropriate since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Apple Podcasts) and lists the available actions (now_playing, play, pause, etc.), which distinguishes it from sibling tools like apple_music or apple_spotify. However, the verb 'Control' is generic and doesn't specify the exact purpose beyond the action list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only implies it's for the Podcasts app, but doesn't mention exclusions (e.g., not for music) or provide context about which action fits which 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?
There are no annotations, and the description gives no behavioral details such as side effects (e.g., opening Spotify search UI), limitations (e.g., AppleScript cannot list playlists directly), or permission requirements. The schema's action descriptions carry the transparency burden, not the main description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Control Spotify.' followed by a compact list of actions. It is concise, free of filler, and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The rich schema covers the action semantics, but the description itself omits important contextual details like the confirm parameter for protected actions and how to choose among similar actions (play vs playpause vs play_track). It is adequate but not fully complete for a tool with 17 actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed explanations for the action enum and all parameters. The description adds little beyond listing action names, so it does not improve upon the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Control Spotify' which is a clear verb+resource statement, and the explicit list of actions (play, pause, next, etc.) makes the tool's purpose obvious. It distinguishes from siblings by naming Spotify, though it doesn't explicitly contrast with apple_music or apple_podcasts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like apple_music or apple_podcasts. It simply lists actions without any context on prerequisites, exclusions, or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only lists action names. It does not mention that quit/force_quit are destructive and require confirmation, nor does it describe outcomes or permission requirements. The schema's confirm parameter hints at this, but the description text adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's purpose and then lists all actions. There is no wasted wording, and the action list is useful for a quick scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, 7 actions) and the lack of annotations or output schema, the description is too sparse. It does not explain what the tool returns, what inputs are needed for each action, or how the confirm parameter works, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter descriptions, including detailed explanations for each action enum value, so the description adds no extra parameter semantics. It does not clarify relationships between parameters, such as name being required for most actions or confirm being needed for destructive ones, but the schema already covers the basics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages macOS applications and lists seven specific actions, giving a precise verb+resource scope. This differentiates it from sibling tools like apple_safari or apple_finder, which target individual applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling app-specific tools, nor does it mention alternatives or exclusions. It only lists actions without explaining use cases, leaving the agent to guess which tool is 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?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only lists action names without explaining effects, prerequisites, or consequences (e.g., whether actions are destructive, require confirmation, or return previews). The 'confirm' parameter description in the schema provides some clue, but the tool description itself is silent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a list of actions, front-loaded with the tool's scope. It is concise and every element (the scope and the action list) contributes directly to understanding the tool. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 11 actions, no annotations, and no output schema, yet the description provides only a list of actions. It does not explain how actions relate to parameters, what happens upon execution (e.g., for protected actions), or what return values to expect. The schema covers parameters, but the overall tool behavior remains under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each action in the enum already has a description. The tool description merely repeats the action names without adding extra meaning about how 'path' or 'confirm' should be used. It does not enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Control Pages, Numbers, and Keynote' and enumerates all 11 actions, making the tool's purpose clear. It is specific to iWork apps and distinguishes well from sibling Apple tools, though the verb 'Control' is somewhat generic without the action list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via its scope ('Control Pages, Numbers, and Keynote') and the action list, but provides no explicit guidance on when to use this tool versus alternatives or when not to use it. No alternatives are mentioned, so the usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, permissions, or confirmation requirements. It only lists actions; the schema's 'confirm' parameter mentions protected/destructive actions, but the description itself adds no behavioral context. This is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the resource and an action list. It's brief and readable, though the action list duplicates the schema's enum, making it slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema's complete parameter descriptions and no output schema, the description is adequate for basic invocation. However, it lacks behavioral transparency and usage guidelines, which are important for a tool with 10 actions and potential destructive operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions with 100% coverage. The description adds no new parameter meaning; it only restates action names that are already in the action enum's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Control Apple Photos' and lists specific actions (albums, recent, search, etc.), making the tool's purpose clear. It distinguishes from siblings by naming the resource, though the verb 'control' is broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The name and action list imply usage for Apple Photos tasks, but the description doesn't mention when not to use it or compare to sibling tools like apple_finder or apple_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it merely lists actions without explaining side effects or risks. Actions like 'close' and 'hide_app' imply significant effects, and the description does not warn that some actions may be destructive or require confirmation. The confirm parameter is only described in the schema, not in the tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses an action list for a quick scan. The first clause and the action list have minor redundancy, but overall it is efficient and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 actions, 5 parameters, no output schema), the description plus the rich schema provides adequate context for most operations. However, it lacks guidance on return values (e.g., list_windows likely returns data) and does not clarify the confirm/preview behavior, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, including detailed explanations for each action and parameter. The tool description only repeats the action list without adding new parameter semantics, so it meets the baseline for schema-covered parameters but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Manage macOS windows' and lists concrete actions like minimize, resize, and fullscreen, making the tool's scope clear. It distinguishes from sibling apple_* tools by targeting window management specifically. However, 'manage' is broad and the action list is an overview without detailed semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for macOS window management but provides no explicit when-to-use or alternative guidance. It does not mention that other apple_* tools handle different system aspects, nor does it explain when certain actions (e.g., close vs hide) 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?
No annotations are present, so the description carries the full burden. It adds a useful behavioral caveat about limited AppleScript support and partial results, which is valuable, but it does not disclose authorization needs, side effects, or reversibility for actions. The disclosure is partial but real.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the topic and action list, and contains zero filler. The caveat about partial results is concise and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a moderate complexity of five actions and three well-documented parameters, the description plus schema covers what each action does. However, it lacks output format details, usage guidance, and alternative differentiation, leaving gaps despite the helpful caveat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with per-action meanings for the enum and clear descriptions for query and confirm. The tool description itself adds no parameter details, but the schema already fully documents them, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the resource (Apple Books) and enumerates the supported actions (library, reading_now, collections, search, open), making the tool's purpose clear. While the verb 'Control' is generic, the action list provides specific scope and distinguishes it from sibling Apple 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Although the action list implies use cases, there is no explicit context about when to pick this over sibling tools or what conditions apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It merely lists actions without disclosing side effects, destructive potential (e.g., close_tab, js_execute), or the confirm requirement for protected actions. The confirm parameter is only described in the schema, not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that identifies the resource and enumerates actions. It is concise with no unnecessary filler, making it easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 actions) and lack of output schema or annotations, the description is too thin. It does not explain the confirm mechanism, return behavior, or situations requiring specific actions. The schema provides action definitions, but the description alone is insufficient for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all parameters, including the action enum with per-action descriptions. The description adds no additional parameter semantics beyond listing action names, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Control Google Chrome browser' and lists all supported actions. This distinguishes it from sibling tools like apple_safari by explicitly naming Chrome as the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by 'Control Google Chrome browser' and the action list, but there is no explicit guidance on when to use this tool versus alternatives like apple_safari or when not to use it. No exclusions or preferred scenarios 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only lists action names without explaining side effects or safety. The schema's confirm parameter reveals that some actions may be protected/destructive, but the description itself does not mention this or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is efficiently concise. It earns its place by naming the tool's purpose and actions, though it could be more structured with line breaks. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (100% coverage, enum descriptions) and lack of output schema, the description is adequate but minimal. It does not explain return values or the confirm behavior, but the schema fills those gaps. For a simple tool, this is just barely acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter semantics beyond the schema's detailed action descriptions and level/confirm ranges; it merely repeats the action names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Control') and resource ('macOS system volume'), and enumerates the exact actions (get, set, up, down, mute, unmute, info). This clearly distinguishes it from sibling tools like apple_brightness or apple_system, which target different domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for controlling macOS volume, but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool references are given; the use case is only inferred from the tool name and listed actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, but it only lists action names. It omits that area involves interactive rectangle selection, timed has a default delay, and confirm may be required for protected actions. These behaviors are only revealed in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence followed by a compact action list. There is zero filler or redundant wording; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema richly covers the parameters, but with no output schema or annotations, the description leaves out behavioral context like the confirm requirement and interactive nature of certain actions. It is minimally sufficient for selection but not fully self-contained for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the action enum provides detailed descriptions for each value. The description's action list adds no new meaning beyond what the schema already documents, so it stays at the schema-driven baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Take screenshots on macOS' uses a specific verb and resource, clearly scoped to macOS, and enumerates the available actions (full, clipboard, timed, area, window). This distinctly separates it from sibling Apple tools like brightness, volume, or apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (whenever a screenshot is needed on macOS) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It is clear context but not actionable selection 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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'Read and write' but does not disclose that 'set' and 'clear' are destructive operations, nor that protected actions may require confirmation (hinted by the 'confirm' parameter). This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and then lists the actions. Every word contributes value, with no redundancy or extraneous detail, making it appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers parameters well, but with no annotations or output schema, the description leaves gaps: it does not specify what 'get' returns, nor the confirmation requirement for destructive actions. While adequate for a basic tool, it could be more complete given the absence of structured safety hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for all three parameters, including the meaning of each enum value. The description only repeats 'get, set, clear' without adding new syntax, format details, or edge-case behavior, so the baseline of 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read and write the macOS clipboard' and lists the specific actions 'get, set, clear.' This is a specific verb+resource that distinguishes it from sibling tools like apple_system or apple_finder, which handle different system features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool is for macOS clipboard interactions, and the listed actions imply when each operation would be used. It does not explicitly name alternatives or exclusions, but given the tool's unique scope, the context is sufficient for an agent to select 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It says 'Read' implying non-destructive, but the schema includes a `confirm` parameter that mentions 'protected/destructive action' with no explanation in the description. This discrepancy is not addressed, leaving the agent confused about whether any action could be destructive and what the confirm parameter is for.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a list of actions, front-loading the core purpose. It is appropriately sized given the 19 actions, with zero wasted words. The list is necessary to enumerate capabilities and is presented cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters and no output schema, and the action list in the description provides a high-level overview. However, the `confirm` parameter is not mentioned in the description, leaving a behavioral gap that affects completeness. The enum descriptions in the schema mitigate some incompleteness, but the missing transparency around confirmed actions brings this down.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. Every action enum value has a detailed description, and the `confirm` parameter is explained in the schema. The tool description itself adds no extra parameter semantics, but the schema already provides comprehensive information, so no further compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read macOS system information' with a specific verb and resource, and enumerates all 19 actions. This fully distinguishes it from sibling tools like apple_brightness or apple_music, which target specific apps or features. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description and action list make it clear when to use this tool: whenever macOS system information (battery, disk, CPU, etc.) is needed. While no explicit alternatives are named, no sibling tool overlaps with system information retrieval, so the context is clear. The enum descriptions in the schema further reinforce usage for each action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds the behavioral note that 'Preview has limited AppleScript support,' which is useful context beyond the schema. However, it does not disclose specifics about destructive actions, response formats, or failure modes, leaving gaps about what happens when actions are executed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, then a concise list of actions and a useful limitation note. Every sentence adds value, and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema provides good parameter descriptions and the action list is clear, the description does not explain return values or behavior after execution, and there is no output schema to fill that gap. The AppleScript limitation note is helpful, but for a tool with no output schema, more context on what to expect would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter has a clear description, so the baseline is 3. The description repeats the action names but does not add new meaning beyond the schema's per-action descriptions. It does not explain path or confirm parameters, but the schema already covers these.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Control Preview app' and enumerates the exact actions (open, list_open, close, close_all), making the tool's purpose specific and unambiguous. It distinguishes itself from sibling Apple app tools by explicitly naming Preview as the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for controlling the Preview app when the user needs those specific actions. It does not explicitly mention alternatives or exclusions, but the naming and action list give clear context. The note about limited AppleScript support serves as a usage caveat, warning that actions may be constrained.
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:

[![apple-mcp-server MCP server](https://glama.ai/mcp/servers/lacausecrypto/apple-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/lacausecrypto/apple-mcp-server)

Score Badge

Copy to your README.md:

[![apple-mcp-server MCP server](https://glama.ai/mcp/servers/lacausecrypto/apple-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/lacausecrypto/apple-mcp-server)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lacausecrypto/apple-mcp-server'

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