mcp-mac

by samicokar

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity, as each is prefixed by its domain (e.g., calendar_, contacts_, finder_) and specifies a unique action (e.g., create_event, get_calendars, get_selection). The domains are well-separated, preventing misselection.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern with domain prefixes (e.g., calendar_create_event, contacts_search_people). All use snake_case uniformly, and the naming structure is predictable across all 24 tools, making them easily readable and organized.
Tool Count4/5
With 24 tools, the count is slightly high but reasonable for the broad scope of macOS automation covering multiple domains like calendar, contacts, mail, and notes. Each tool earns its place by addressing specific tasks, though it borders on heavy for a single server.
Completeness4/5
The tool surface provides strong CRUD/lifecycle coverage across domains, with create, get, and search operations for most resources. Minor gaps exist, such as no update/delete for calendar events or notes, but agents can work around these for core workflows.
Average 3/5 across 24 of 24 tools scored.
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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create new calendar event' implies a write/mutation operation, but it doesn't disclose any behavioral traits: no information about permissions required, whether creation is immediate or scheduled, what happens on conflicts, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this is a significant gap in 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 maximally concise at just three words, front-loading the essential information with zero wasted language. Every word earns its place: 'Create' specifies the action, 'new' clarifies it's not an update, and 'calendar event' identifies the resource. This is an excellent example of efficient communication.
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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address what happens after creation (success/failure responses), doesn't mention authentication requirements, and provides no context about the calendar system's behavior. Given the complexity of calendar event creation (which involves scheduling logic, potential conflicts, and timezone considerations), the description should provide more 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?
The description adds no parameter information beyond what's already in the schema, which has 100% coverage with detailed descriptions for all 5 parameters. The baseline score of 3 reflects that the schema adequately documents parameters, so the description doesn't need to compensate. However, it also doesn't provide any additional context about parameter relationships or usage patterns.
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 'Create new calendar event' clearly states the action (create) and resource (calendar event), making the purpose immediately understandable. It distinguishes from sibling tools like calendar_get_calendars or calendar_get_today_events by focusing on creation rather than retrieval. However, it doesn't specify what makes a 'calendar event' distinct from other event-like resources in the system.
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. With sibling tools like reminders_create_reminder and notes_create_note available, there's no indication of whether this is for time-blocked appointments versus other types of scheduling or event tracking. The description lacks any context about prerequisites, appropriate scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the basic function but lacks critical details: whether it requires authentication, rate limits, what format events are returned in, pagination behavior, or error conditions. For a read operation with zero annotation coverage, this is insufficient.
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 extremely concise at just 5 words, front-loading the core purpose with zero wasted words. Every element ('Get upcoming events in date range') directly 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?
For a tool with no annotations, no output schema, and multiple sibling calendar tools, the description is incomplete. It doesn't explain what 'upcoming events' means operationally, how results are structured, or how it differs from similar tools. The agent would need to guess about return format and behavioral characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (the 'days' parameter is fully documented in the schema), so the baseline is 3. The description adds no additional parameter information beyond what's already in the schema, maintaining the minimum viable level.
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 action ('Get upcoming events') and scope ('in date range'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'calendar_get_today_events' or 'calendar_get_calendars', which prevents 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 like 'calendar_get_today_events' or 'calendar_get_calendars'. There's no mention of prerequisites, exclusions, or specific contexts where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but does not mention whether this is a read-only operation, if it requires authentication, potential rate limits, or what the output format might be. This leaves significant gaps in understanding the tool's 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, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 lack of annotations and output schema, the description is incomplete. It does not explain what 'detailed information' includes, how errors are handled, or any behavioral traits, making it insufficient for a tool that retrieves person-specific data without structured output documentation.
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% description coverage, with the parameter 'person_name' clearly documented as 'Full name of the person to get info for'. The description adds no additional semantic context beyond this, so it meets the baseline for high schema coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information for a specific person', making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'contacts_search_people', which might be used for broader searches rather than retrieving details for a specific individual.
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, such as 'contacts_search_people' for finding people or other tools for different contact-related tasks. It lacks context on prerequisites or exclusions, leaving usage unclear.
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 the basic function without mentioning important aspects like whether this is a read-only operation, how results are returned (e.g., pagination, format), performance characteristics, or error conditions. The description is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's function without any unnecessary words. It's front-loaded with the core purpose and efficiently communicates the essential information.
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 search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the search returns (e.g., list of matching contacts, their details), search behavior (e.g., partial matches, case sensitivity), or limitations. The minimal description leaves too many questions unanswered for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'search_term' well-documented in the schema as 'Name or part of name to search for'. The description adds no additional parameter semantics beyond what's already in the schema, so it meets 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 action ('Search for people') and the resource ('in Contacts'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'contacts_get_person_info', which appears to retrieve detailed information about a specific person rather than searching by 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?
The description provides no guidance on when to use this tool versus alternatives like 'contacts_get_person_info' or other search tools. It mentions searching by name but doesn't specify use cases, prerequisites, or limitations beyond the basic parameter.
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 full burden for behavioral disclosure. It mentions 'discover' which implies a read operation, but doesn't specify what happens during discovery, whether it requires specific permissions, what the output looks like, or any side effects. For a tool with 3 required parameters and no annotations, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. It's appropriately sized for the tool's complexity and contains no unnecessary words. Every word earns its place in conveying the core purpose.
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 3 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the discovery results look like, how they're saved, what the different methods do, or any behavioral characteristics. For a tool that presumably generates output files and has multiple discovery methods, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters with clear descriptions. The description doesn't add any additional parameter semantics beyond what's in the schema. It mentions 'AppleScript capabilities' which relates to the purpose but doesn't elaborate on parameter meanings. Baseline 3 is appropriate when 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's purpose: 'Discover AppleScript capabilities of a macOS application.' It specifies the verb ('discover') and resource ('AppleScript capabilities'), but doesn't differentiate from siblings since this appears to be the only AppleScript-related tool in the server. The purpose is specific but lacks sibling comparison context.
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 doesn't mention prerequisites, timing considerations, or when not to use it. With many sibling tools for different macOS applications, some implicit context exists, but no explicit usage guidelines are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention whether this actually sends the email, saves it as a draft, requires specific permissions, has rate limits, or what happens on success/failure. For a tool that presumably creates email messages, this leaves critical behavioral aspects undocumented.
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, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a straightforward creation tool and gets directly to the point with zero wasted verbiage.
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 that creates email messages with no annotations and no output schema, the description is insufficient. It doesn't clarify the relationship with 'mail_send_message', doesn't explain what happens after creation (draft vs. sent), and provides no behavioral context. Given the complexity of email operations and the lack of structured metadata, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions recipients, subject, and body which aligns with the required parameters, but adds no additional semantic context beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
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 action ('create new email message') and specifies key components (recipients, subject, body), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling 'mail_send_message' tool, which appears to be a related but distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'mail_send_message' or other communication tools. There's no mention of prerequisites, typical use cases, or when not to use it, leaving the agent with insufficient context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('send') but doesn't clarify what 'send' entails (e.g., whether it's irreversible, requires network connectivity, or has side effects like moving the message to a sent folder). It also doesn't mention error conditions or what happens if no recent message exists. This leaves significant gaps in understanding the tool's 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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by conveying essential information without redundancy or fluff.
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 (it performs a send action with no parameters but relies on implicit context), lack of annotations, and no output schema, the description is incomplete. It doesn't explain how the 'most recently created message' is determined, what the send operation does, or what the expected outcome is (e.g., success/failure indicators). For a context-dependent tool with no structured support, more detail is needed to ensure reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is appropriate since there are none. However, it implicitly suggests the tool operates on context (the 'most recently created message'), but this isn't a formal parameter. Given the lack of parameters, a baseline of 4 is justified as the description doesn't need to compensate for missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send the most recently created message' states a specific action (send) on a specific resource (most recently created message), which is clear. However, it doesn't distinguish this tool from potential alternatives like 'mail_create_message' or explain what qualifies as 'most recently created message' (e.g., from which context or application). This makes the purpose somewhat vague in practice.
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 doesn't mention prerequisites (e.g., that a message must have been created first, possibly using 'mail_create_message'), exclusions, or contextual cues. Without such information, an agent might misuse it or overlook necessary preparatory steps.
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 burden for behavioral disclosure. It states 'Create new note' which implies a write/mutation operation, but doesn't mention permissions needed, whether creation is immediate or requires confirmation, error handling, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is insufficient.
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 extremely concise at just 6 words, with zero wasted language. It's front-loaded with the core action ('Create new note') and specifies key parameters. Every word earns its place, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after creation (e.g., returns note ID, opens the note, etc.), error conditions, or behavioral constraints. Given the complexity of a write operation and lack of structured coverage, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (title, content, folder) with their types and descriptions. The description mentions 'title and content' which aligns with required parameters but adds no additional semantic context beyond what's in the schema. Baseline 3 is appropriate when 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 verb ('Create') and resource ('new note'), specifying what the tool does. It distinguishes from siblings like notes_get_recent_notes (read) and notes_search_notes (search), but doesn't explicitly differentiate from other creation tools like calendar_create_event or reminders_create_reminder beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites, when-not-to-use scenarios, or compare with similar creation tools like textedit_create_document or mail_create_message. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify what 'recently modified' means (timeframe criteria), whether results are sorted, what format they return, or any limitations. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 extremely concise at just three words ('Get recently modified notes'), front-loading the core purpose with zero wasted words. Every word earns its place in communicating the essential 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 no annotations, no output schema, and a read operation that likely returns structured data, the description is insufficient. It doesn't explain what 'recently modified' means, what data is returned, how results are ordered, or any limitations. For a tool that presumably returns multiple notes with timestamps, this leaves too much undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with the 'limit' parameter clearly documented. The description doesn't add any parameter information beyond what's in the schema. With high schema coverage and only one parameter, the baseline score of 3 is appropriate - the schema does the heavy lifting for parameter documentation.
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 'Get recently modified notes' clearly states the verb ('Get') and resource ('recently modified notes'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'notes_search_notes' or 'notes_get_folders' - it's clear what it does but not how it differs from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'notes_search_notes' or 'notes_get_folders'. There's no mention of use cases, prerequisites, or when this tool would be preferred over other notes-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool searches notes but doesn't disclose behavioral traits such as whether it's read-only (implied but not explicit), how results are returned (e.g., list format, pagination), error handling, or any limitations like search performance or scope constraints. This leaves significant gaps for a search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple search tool, making it easy to parse quickly.
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 (a search operation with no output schema and no annotations), the description is incomplete. It lacks details on return values, result format, error cases, or behavioral constraints. While concise, it doesn't provide enough context for reliable agent use without additional assumptions.
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% description coverage, with the 'query' parameter fully documented. The description adds minimal value beyond the schema by specifying 'by title or content', which slightly clarifies the search scope but doesn't provide additional syntax, format, or examples. This meets 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 verb ('search') and resource ('notes'), specifying the search scope ('by title or content'). However, it doesn't differentiate from sibling tools like 'notes_get_recent_notes' or 'notes_create_note', which would require mentioning this is specifically for text-based searching rather than listing or creating notes.
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 doesn't mention when to choose this over 'notes_get_recent_notes' for finding notes, or any prerequisites like needing existing notes to search. There's only an implied usage from the purpose statement.
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 states the tool creates a reminder but doesn't describe what happens after creation (e.g., success/failure response, whether the reminder is immediately visible), permission requirements, or any side effects. For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence that front-loads the core purpose ('Create new reminder') and lists key optional parameters. There is no wasted verbiage or redundancy, making it highly concise and well-structured for quick comprehension.
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 (a mutation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, response format, or integration with sibling tools (e.g., using 'reminders_get_lists' to validate the list parameter). The description meets minimal needs but leaves critical gaps for effective agent use.
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 description mentions title, due date, and list parameters, but the input schema already has 100% coverage with clear descriptions for all four parameters (including notes). The description adds minimal value beyond the schema, as it doesn't explain parameter interactions or provide additional context like format examples beyond what's in the schema 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 clearly states the action ('Create new reminder') and specifies the key attributes (title, optional due date and list). It distinguishes from sibling tools like 'reminders_get_incomplete_reminders' by focusing on creation rather than retrieval. However, it doesn't explicitly differentiate from other creation tools like 'notes_create_note' or 'calendar_create_event' beyond the domain context.
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 doesn't mention prerequisites (e.g., needing access to reminders), when not to use it (e.g., for updating existing reminders), or how it relates to sibling tools like 'reminders_get_lists' for list validation. Usage is implied by the creation context but not explicitly stated.
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 burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the incomplete reminders come in. The description is minimal and lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it efficiently front-loaded.
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 no annotations, no output schema, and minimal description, this is inadequate. The description doesn't explain what 'incomplete reminders' means, what data is returned, or any behavioral constraints. Given the complexity of accessing reminder data across systems, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with one parameter ('limit') fully documented in the schema. The description doesn't add any parameter information beyond what's already in the schema, which is acceptable given the high schema coverage, resulting in the 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 verb ('Get') and resource ('incomplete reminders across all lists'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'reminders_get_lists' or 'reminders_create_reminder', which would require 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use it over other reminder-related tools or when it's appropriate versus other methods of accessing reminders.
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 states the tool creates a document but doesn't cover critical aspects like whether it requires specific permissions, what happens to the document after creation (e.g., saved location), or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Create new TextEdit document') and includes the key detail ('with optional content'). There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., document ID, success status), potential side effects, or usage constraints. For a creation tool with these gaps, more contextual information is needed.
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 description mentions 'optional content', which aligns with the single parameter 'content' in the schema. Since schema description coverage is 100%, the baseline is 3. The description adds minimal value beyond the schema's documentation of the parameter as optional initial content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new TextEdit document'), making the purpose immediately understandable. It distinguishes from sibling tools like 'textedit_get_documents' by focusing on creation rather than retrieval. However, it doesn't explicitly differentiate from other creation tools like 'notes_create_note' or 'workflow_contact_to_textedit', which prevents 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. It doesn't mention prerequisites (e.g., TextEdit availability), exclusions, or comparisons to similar tools like 'notes_create_note' or 'workflow_contact_to_textedit'. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions 'get contact information' and 'create formatted TextEdit document,' implying a read operation followed by a write operation, but doesn't detail permissions, formatting specifics, error handling, or output behavior. This is inadequate for a tool that performs multiple actions without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get contact information and create formatted TextEdit document.' It is front-loaded with the core purpose, has no redundant words, and every part contributes directly to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (combining contact lookup and document creation) and lack of annotations or output schema, the description is insufficient. It doesn't explain the workflow, how data is formatted, what the output looks like, or potential errors. This leaves significant gaps for an agent to understand and use the tool effectively.
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% description coverage, with parameters 'name' and 'title' clearly documented. The description doesn't add any semantic details beyond the schema, such as formatting rules or lookup constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles parameter documentation effectively.
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: 'Get contact information and create formatted TextEdit document.' It specifies the verb ('get' and 'create') and resources ('contact information' and 'TextEdit document'), making the action clear. However, it doesn't differentiate from sibling tools like 'contacts_get_person_info' or 'textedit_create_document', which handle similar operations separately.
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 doesn't mention sibling tools such as 'contacts_get_person_info' for getting contact info or 'textedit_create_document' for creating documents, nor does it specify prerequisites or exclusions. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if this requires specific permissions, how it handles no selection, or what the return format is (e.g., list of paths), which is critical for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 no annotations and no output schema, the description is incomplete for effective tool use. It lacks details on return values (e.g., format, handling of empty selections) and behavioral context, which are essential for an agent to invoke this tool correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description correctly avoids discussing parameters, aligning with the empty input schema, which justifies a baseline score of 4 for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('currently selected files/folders in Finder'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'finder_get_current_folder', which retrieves a different Finder state, so it misses the highest 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?
No guidance is provided on when to use this tool versus alternatives. The description implies usage when needing the current Finder selection, but it doesn't specify prerequisites (e.g., Finder must be active) or compare to siblings like 'finder_get_current_folder' for context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation without disclosing behavioral traits such as permissions needed, rate limits, freshness of data, or error conditions. It's minimal and lacks depth for a tool that likely interacts with user data.
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, clear sentence with no wasted words, making it highly efficient and easy to parse. It's front-loaded and 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 params, no output schema), the description is minimal but adequate for basic understanding. However, without annotations or output details, it fails to provide complete context for safe and effective use, such as what the count represents or any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but this is acceptable given the lack of inputs, aligning with the baseline for zero parameters.
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 action ('Get') and resource ('total message count in inbox'), making the tool's purpose immediately understandable. However, it doesn't differentiate from its sibling 'mail_get_inbox_count', which appears to serve a similar function, preventing 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 like 'mail_get_inbox_count' or other mail-related tools. It lacks context about prerequisites, timing, or comparison with siblings, leaving usage decisions ambiguous.
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 states the action but doesn't cover important traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what the return format looks like (e.g., list structure, pagination). This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain behavioral aspects like safety, authentication needs, or the structure of returned data (e.g., what 'note counts' entail). For a tool with no structured support, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no parameters are required by not mentioning any. This meets the baseline for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all note folders with note counts', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'notes_get_recent_notes' or 'notes_search_notes', which prevents 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 like 'notes_get_recent_notes' or 'notes_search_notes'. It lacks any context about prerequisites, timing, or exclusions, leaving usage unclear.
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 burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves—no information about permissions needed, rate limits, pagination, error handling, or what 'reminder counts' entail. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'reminder lists' or 'reminder counts' mean in the return value, nor does it cover behavioral aspects like error cases or performance. For a tool with such sparse structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any, earning a baseline score for this scenario.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all reminder lists with reminder counts'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'reminders_get_incomplete_reminders' which suggests it could be more specific about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'reminders_get_incomplete_reminders' or 'reminders_create_reminder'. There's no mention of prerequisites, context, or exclusions, leaving usage unclear.
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 burden for behavioral disclosure. It states the operation is a 'Get' (implying read-only) and returns calendars with event counts, but lacks details on permissions needed, rate limits, pagination, error handling, or what 'all calendars' entails (e.g., personal vs. shared). This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the core action ('Get all calendars') and adds necessary detail ('with event counts') concisely. Every part of the sentence earns its place by specifying the resource and additional data returned.
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 has no parameters (simplifying input) and no output schema, the description adequately covers the basic purpose but lacks completeness. It doesn't explain the return format (e.g., list structure, event count details) or behavioral aspects like error cases. For a read operation with no annotations, more context on output and constraints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as it avoids redundancy while clearly stating the tool's function without parameter confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all calendars'), with the additional detail 'with event counts' specifying what information is retrieved. It distinguishes from siblings like calendar_get_today_events or calendar_get_upcoming_events by focusing on calendars themselves rather than events. However, it doesn't explicitly differentiate from other calendar-related tools beyond scope.
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 doesn't mention prerequisites, context for retrieving calendars versus events, or comparisons to sibling tools like calendar_get_today_events. Usage is implied by the action but not explicitly defined.
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 burden for behavioral disclosure. It states what the tool does but doesn't describe return format, pagination, error conditions, authentication requirements, or whether it's a read-only operation. 'Get list' implies reading, but explicit confirmation would help.
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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool with no parameters and gets straight to the point.
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 zero-parameter tool with no output schema, the description adequately states what it does. However, without annotations or output details, it lacks information about return format, error handling, and how results might be used with sibling tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the empty input. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose without unnecessary repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of all Mail account names'), making the purpose immediately understandable. However, it doesn't differentiate from sibling mail tools like 'mail_get_inbox_count' or 'mail_get_total_inbox_count' beyond the resource scope.
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 doesn't mention prerequisites, timing considerations, or how it relates to sibling tools like 'mail_create_message' or 'mail_send_message' that might require account selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information on permissions needed, rate limits, whether it's cached or real-time, error conditions, or what format the count is returned in. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's front-loaded with the core functionality ('Get unread message count') and specifies the scope ('in inbox'). Every word earns its place in this minimal but complete statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with zero parameters and no output schema, the description is minimally complete. It tells the agent what the tool returns (unread count) but doesn't provide context about the return format, units, or possible edge cases. Given the low complexity, it's adequate but leaves the agent to assume details about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain any parameters, which is appropriate. It correctly focuses on the tool's purpose rather than parameter details. A baseline of 4 is given for zero-parameter tools when the description is adequate for the function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('unread message count in inbox'), making the purpose immediately understandable. It distinguishes from sibling 'mail_get_total_inbox_count' by specifying 'unread' messages rather than total count. However, it doesn't explicitly mention the data source or system (e.g., email client), which prevents 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. There's no mention of prerequisites, context for usage, or comparison with sibling tools like 'mail_get_total_inbox_count' or 'mail_get_accounts'. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a list but doesn't specify what 'open' means (e.g., currently loaded in memory, recently accessed), the format of the returned list, or any limitations like rate constraints. This leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly.
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 (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks depth. It doesn't explain what 'open' entails or the structure of the returned list, which could be important for an agent to use the tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is acceptable here since there are no parameters to explain, aligning with the baseline for zero parameters.
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 action ('Get list') and resource ('open TextEdit documents'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'textedit_create_document' by focusing on retrieval rather than creation. However, it doesn't specify if this includes all documents or just those in a particular state beyond 'open'.
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. It doesn't mention any prerequisites, such as needing TextEdit running, or compare it to other tools like 'notes_get_recent_notes' for similar functionality. The description lacks context for decision-making.
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 burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects like whether it returns all-day events, how it handles time zones, what format events are returned in, or if there are any rate limits or authentication requirements. This leaves significant gaps for an agent to understand how to properly use the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's front-loaded with the essential information and every word earns its place, making it easy for an agent to quickly understand what the tool does.
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 no annotations and no output schema, the description is incomplete for proper tool usage. While concise, it lacks critical information about return format, error conditions, behavioral constraints, and how it differs from similar tools. For a tool that presumably returns structured event data, more context about what 'events' includes would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose. This meets the baseline expectation for parameter-free tools.
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 action ('Get') and resource ('today's events across all calendars'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling 'calendar_get_upcoming_events' beyond the temporal scope ('today' vs 'upcoming'), which could be more explicit about the distinction.
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 context through 'today's events' and 'across all calendars', suggesting it's for retrieving current-day calendar items without filtering. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'calendar_get_upcoming_events' or mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavior (retrieves a path) but lacks details on error conditions (e.g., if no Finder window is open), return format, or system dependencies. It adds basic context but misses operational specifics.
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, efficient sentence that front-loads the core purpose with zero wasted words. It directly communicates the tool's function without redundancy or unnecessary elaboration.
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 low complexity (0 parameters, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose but lacks details on output (e.g., path format) and error handling, which would enhance completeness for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is high. The description adds value by clarifying the target ('currently viewed folder in frontmost Finder window'), which the empty schema cannot convey, though it doesn't need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get path') and target resource ('currently viewed folder in frontmost Finder window'), with no ambiguity. It distinguishes itself from sibling tools like 'finder_get_selection' by focusing on the current folder path rather than selected items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when a Finder window is active and frontmost) but does not explicitly state when to use this tool versus alternatives or provide exclusions. No sibling tool directly overlaps, but guidance on prerequisites (e.g., Finder must be running) is missing.
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:

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

Score Badge

Copy to your README.md:

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

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/samicokar/mcp-mac'

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