Apple Notes MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct by resource (folders vs. notes) and action, but some overlap exists: notes.search and notes.index_search both handle search, though one uses Apple's native search and the other a local index, which could cause confusion. Similarly, notes.append_text and notes.update both allow appending text, though update offers more flexibility.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern with dot notation for grouping (e.g., folders.contents, notes.create). All tools use snake_case consistently, and verbs like 'list', 'get', 'create', 'update', 'delete' are applied predictably across resources.
Tool Count3/5
With 24 tools, the count is on the high side for a notes management server, bordering on heavy. While it covers many operations, some tools like notes.index_build, notes.index_search, and notes.index_status for local indexing might be overkill for typical note-taking workflows, suggesting potential scope creep.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage for Apple Notes, including folder management, note creation, reading, updating, deleting, moving, searching, and formatting. It also includes advanced features like checklists, links, templates, and server controls, leaving no obvious gaps for the domain.
Average 3.6/5 across 24 of 24 tools scored. Lowest: 2.9/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 is failing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutable operation (readOnlyHint: false) that is non-destructive (destructiveHint: false) and closed-world (openWorldHint: false), but the description adds minimal behavioral context. It implies the tool can toggle or set a boolean state, which aligns with the 'checked' parameter, but doesn't detail effects (e.g., if it updates a note in place) or constraints (e.g., rate limits). The description doesn't contradict annotations, so it's scored based on adding some value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core action without unnecessary words. It's front-loaded with the main purpose, making it easy for an agent to parse quickly. Every part of the sentence serves a purpose, achieving optimal conciseness.
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 (3 parameters, 2 required) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations covering behavioral nuances and low schema coverage, it should provide more context on usage and parameters to be fully helpful. It meets a baseline but has clear gaps in guidance and semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation in the schema. It mentions 'by index', which hints at the 'index' parameter, but doesn't explain 'id' (likely a note or checklist identifier) or 'checked' (the boolean to set). This leaves two of three parameters inadequately described, failing to fully address the schema gap.
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 states the action ('toggle or set') and target ('checklist item by index'), which clarifies the tool's purpose beyond the title. However, it doesn't distinguish this tool from sibling tools like 'notes.add_checklist' or 'notes.remove_checklist'—it mentions toggling/setting but not how it differs from adding or removing checklist items, leaving some ambiguity about its specific role.
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 an existing checklist), exclusions, or comparisons to siblings like 'notes.add_checklist' or 'notes.remove_checklist'. Without such context, an agent might struggle to choose the correct tool for modifying checklist items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-destructive, closed-world operation, but the description adds minimal behavioral context. It implies a mutation (removal) without specifying effects like whether the removal is permanent, if indices shift after removal, or any error conditions. The description doesn't contradict annotations but adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it easy to parse. It front-loads the core action and target efficiently, though this brevity contributes to gaps in other dimensions.
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 (mutation with 2 parameters), lack of schema descriptions, and presence of an output schema (which handles return values), the description is incomplete. It covers the basic purpose but misses key details like parameter meanings, usage context, and behavioral nuances, relying too heavily on the output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 2 parameters, the description fails to compensate by explaining 'id' (e.g., note ID, checklist ID) or 'index' (e.g., zero-based position). It only mentions 'index' generically, leaving both parameters semantically unclear beyond their basic types 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 action ('Remove') and target ('checklist item by index'), which is specific and actionable. However, it doesn't differentiate from sibling tools like 'notes.toggle_checklist' or 'notes.delete' that might also modify checklists or notes, leaving some ambiguity about when to choose this specific removal method.
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.toggle_checklist' or 'notes.update'. It lacks context about prerequisites (e.g., needing an existing checklist), exclusions, or typical scenarios for index-based removal, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, indicating this is a safe read operation with limited scope. The description adds minimal behavioral context beyond this - it mentions listing contents but doesn't describe return format, pagination, error conditions, or performance characteristics. With annotations covering safety and scope, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without any wasted words. It's front-loaded with the essential information and has perfect conciseness for this level of tool complexity.
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 that this tool has annotations covering safety/scope and an output schema exists (so return values are documented elsewhere), the description is minimally adequate. However, for a tool with 3 parameters (one required) and 0% schema coverage, the description should provide more parameter context and usage guidance to be truly complete.
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?
With 0% schema description coverage, the schema provides no parameter documentation. The description mentions 'folder path' which maps to the 'path' parameter, but doesn't explain the 'recursive' or 'limit' parameters. It adds some value by clarifying what 'path' represents, but doesn't compensate for the complete lack of documentation on the other two 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 ('List') and resources ('notes and subfolders') with the scope ('for a folder path'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'notes.list' or 'notes.list_folders' which might have overlapping functionality.
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.list' or 'notes.list_folders'. It states what the tool does but offers no context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutation tool (readOnlyHint: false) that is not destructive (destructiveHint: false) and operates in a closed world (openWorldHint: false). The description adds minimal behavioral context beyond this—it implies the folder must exist at the given path and will be renamed, but doesn't detail effects (e.g., whether it affects nested items, permissions, or error handling). With annotations covering safety and world assumptions, the description adds some value but lacks depth on operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 ('Rename a folder') and adds necessary context ('at nested path') concisely. Every part earns its place by clarifying scope without 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?
Given the tool has annotations (covering mutation, safety, and world assumptions) and an output schema (which handles return values), the description's minimalism is somewhat acceptable. However, for a mutation tool with 0% schema coverage and no usage guidelines, it lacks completeness in explaining parameter semantics and when to use it. It meets a bare minimum but leaves gaps in 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 0%, so parameters 'path' and 'newName' are undocumented in the schema. The description mentions 'nested path', which hints at the 'path' parameter's purpose, but doesn't explain 'newName' or provide format details (e.g., path syntax, name constraints). It adds marginal meaning but doesn't fully compensate for the schema gap, aligning with the baseline when schema coverage is low.
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 ('Rename') and resource ('a folder at nested path'), making the purpose immediately understandable. It distinguishes from siblings like folders.delete (deletion) and folders.contents (listing), though it doesn't explicitly differentiate from notes.move (which moves notes, not folders). The description is specific but could be more precise about what distinguishes it from all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 the folder to exist), exclusions (e.g., not for renaming notes), or direct alternatives like notes.move for moving notes. Without such context, the agent must infer usage from the tool name and siblings alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-destructive, closed-world tool, which the description doesn't contradict. The description adds minimal behavioral context by implying an 'append' operation that adds items without overwriting, but it lacks details on permissions, rate limits, or error handling, offering only basic value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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's front-loaded and wastes no space, 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 moderate complexity (2 required parameters, no nested objects) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context on usage scenarios, parameter details, and behavioral nuances, leaving gaps in overall 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?
With 0% schema description coverage, the description doesn't explain the parameters 'id' or 'items' beyond what's implied by the tool name. It hints that 'items' are checklist items to append, but provides no details on format or constraints. This partially compensates for the low schema coverage but remains vague, aligning with the baseline expectation.
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 ('Append') and resource ('checklist items to a note'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'notes.toggle_checklist' or 'notes.remove_checklist', which also manipulate checklists in notes, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 an existing note), exclusions, or comparisons to tools like 'notes.toggle_checklist' or 'notes.remove_checklist', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-destructive, non-read-only mutation (readOnlyHint: false, destructiveHint: false), which the description aligns with by implying modification ('Append'). However, the description adds minimal behavioral context beyond annotations—it doesn't specify effects like whether the link is added at a specific position, if duplicates are allowed, or any rate limits. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 and wastes no space, 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.
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 (3 parameters, mutation operation) and the presence of an output schema (which reduces need to describe returns), the description is minimally adequate. However, it lacks details on parameter usage, behavioral nuances, and sibling differentiation, leaving gaps that could hinder optimal tool 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?
With 0% schema description coverage, the schema provides no parameter details, but the description also adds no information about parameters like 'id', 'url', or 'text'. It implies parameters are needed for appending a link but doesn't explain their roles or formats. Baseline is 3 due to the schema's lack of descriptions, but the description fails to compensate meaningfully.
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 ('Append') and resource ('hyperlink to a note'), making the purpose immediately understandable. It distinguishes from siblings like 'notes.append_text' by specifying hyperlinks rather than general text, though it doesn't explicitly contrast with all similar tools like 'notes.update' which might also modify 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 such as 'notes.append_text' for plain text or 'notes.update' for broader modifications. It lacks context about prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, indicating this is a non-destructive write operation without open-world assumptions. The description adds that it appends 'plain text' (not formatted content) to a 'note body', which provides useful context beyond annotations. However, it doesn't mention rate limits, authentication needs, or what happens if the note doesn't exist.
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 wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place 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 moderate complexity (mutation with 2 parameters), annotations cover safety aspects, and an output schema exists (so return values are documented elsewhere), the description is minimally adequate. However, it lacks guidance on usage versus siblings and doesn't fully address parameter semantics given the 0% schema coverage, leaving gaps in contextual understanding.
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?
With 0% schema description coverage, the schema provides no parameter documentation. The description mentions 'note body' (implied target) and 'plain text' (implied content), which loosely map to the 'id' and 'text' parameters but lack specifics like format requirements or constraints. It adds marginal semantic value but doesn't fully compensate for the schema coverage gap.
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 ('Append plain text') and target resource ('to a note body'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like notes.update or notes.apply_format, which might also modify note content. The purpose is unambiguous but lacks 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 guidance on when to use this tool versus alternatives like notes.update, notes.add_checklist, or notes.apply_format. It doesn't mention prerequisites (e.g., note must exist), exclusions, or comparative context with sibling tools. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readonly, non-destructive, closed-world operation. The description adds that it 'overwrites' note body content, which aligns with annotations (non-readonly but non-destructive for the note itself). However, it doesn't disclose additional behavioral traits like authentication needs, rate limits, or what 'overwrite' entails for existing content.
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 key action ('Overwrite a note body') and specifies the outcome ('professional action plan with headings, lists, timestamp'). No wasted words 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?
Given the tool has an output schema (which handles return values), annotations cover basic safety, and it's a mutation tool with 3 parameters, the description is minimally adequate. However, it lacks details on parameter usage, error conditions, or how the template is applied, leaving gaps in context for effective 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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description mentions 'note body' but doesn't explain the three parameters (id, title, context) or their roles in applying the template. Baseline is 3 since schema coverage is low, but the description doesn't compensate by clarifying parameter meanings.
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 ('Overwrite') and resource ('note body') with specific content ('professional action plan with headings, lists, timestamp'). It distinguishes from generic update tools but doesn't explicitly differentiate from siblings like 'notes.apply_format' or 'notes.update'.
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 like 'notes.update', 'notes.apply_format', or 'notes.append_text'. The description implies it's for transforming notes into action plans but doesn't specify prerequisites, exclusions, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-destructive, closed-world operation. The description adds that it applies formatting to the 'entire note body', which clarifies scope beyond annotations. However, it doesn't detail side effects, permissions, or rate limits, relying on annotations for core 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.
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 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and annotations covering safety, the description is adequate but minimal. It lacks details on parameter usage, error conditions, or formatting specifics, which could be helpful for a mutation tool despite structured data.
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 0%, but the description doesn't explain the parameters 'id' or 'mode'. The schema provides an enum for 'mode', but the description doesn't add meaning beyond the basic action. With two parameters and no schema descriptions, this is a minimal baseline.
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 ('apply simple formatting') and the target ('entire note body'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential formatting alternatives among its siblings, such as 'notes.append_text' or 'notes.update', which might also affect formatting.
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, exclusions, or compare it to other formatting-related tools like 'notes.update' or 'notes.append_text', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutable (readOnlyHint: false), non-destructive operation (destructiveHint: false) in a closed world (openWorldHint: false). The description adds that it moves a note to another folder, which aligns with annotations but doesn't provide extra behavioral details like permission requirements, error conditions, or rate limits. It neither contradicts nor significantly enriches the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core action ('Move a note') and directly states the method ('by folderId or path'), making it easy to parse quickly without 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 has an output schema (which handles return values), annotations covering safety, and low parameter complexity, the description is minimally adequate. However, it lacks details on usage context, parameter interactions, and behavioral nuances, leaving gaps that could hinder effective tool invocation despite the structured data.
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?
With 0% schema description coverage, the schema provides no parameter details. The description mentions 'folderId or path' for the destination, hinting at 'toFolderId' and 'toPath' parameters, but doesn't explain 'id' or clarify if both destination parameters are required or mutually exclusive. It adds some meaning but doesn't fully compensate for the low 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 ('Move') and resource ('a note'), specifying the action of moving to another folder using folderId or path. However, it doesn't explicitly differentiate from sibling tools like 'notes.update' or 'folders.rename', which might also involve location changes, so it doesn't reach the highest clarity level.
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, such as needing an existing note ID, or compare it to similar tools like 'notes.update' for modifying note properties. Without any usage context or exclusions, it offers minimal practical help for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering key behavioral traits. The description adds minimal context by specifying it affects 'write ops,' but doesn't elaborate on side effects, permissions, or system impact beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, front-loading the core action. It's appropriately sized for a simple toggle tool with one parameter.
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 (1 boolean parameter) and the presence of annotations and an output schema, the description is minimally adequate. However, it lacks details on system-wide implications or error conditions, which could be helpful for safe mode management.
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 0%, but there's only one parameter (safe) with a boolean type. The description implies 'safe' controls read-only mode for writes, adding some meaning beyond the schema's bare type definition. However, it doesn't detail default states or effects, keeping it at a baseline 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 verb ('Enable/disable') and resource ('safe (read-only) mode for write ops'), making the purpose understandable. However, it doesn't differentiate this tool from its siblings (like server.status or various notes/folders tools), 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, prerequisites, or exclusions. It merely restates the action without context, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover key behavioral traits: readOnlyHint=false (write operation), destructiveHint=false (non-destructive), openWorldHint=false (closed-world). The description adds that it creates a 'new' note, which aligns with annotations and provides context on the action. However, it doesn't disclose additional behaviors like permissions needed, rate limits, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 a new note') and lists optional parameters without unnecessary details. 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.
Completeness4/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 (creation with optional params), annotations cover safety traits, and an output schema exists (so return values needn't be explained), the description is reasonably complete. It specifies the action and parameters, though it could benefit from more context on usage and parameter details.
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 0%, so the schema provides no parameter details. The description mentions optional parameters (folder, title, body), adding basic semantics beyond the schema. However, it doesn't explain parameter formats (e.g., folderId structure), constraints, or defaults, leaving gaps in 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 clearly states the verb 'Create' and resource 'note', specifying it's a new note with optional fields. It distinguishes from siblings like notes.update or notes.append_text by focusing on initial creation. However, it doesn't explicitly differentiate from all siblings (e.g., notes.add_checklist might also create content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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., folder existence), when not to use it (e.g., for updating existing notes), or direct alternatives among siblings like notes.apply_action_plan_template. Usage is implied 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe read operation with closed-world data. The description adds no behavioral context beyond this, such as error handling for invalid IDs or performance characteristics. It doesn't contradict annotations, but adds little value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, read-only operation) and the presence of an output schema (which handles return values), the description is reasonably complete for basic use. However, it lacks details on error cases or integration with sibling tools, leaving minor gaps in 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?
With 0% schema description coverage, the schema provides no parameter details. The description mentions 'by ID', implying the 'id' parameter is for note identification, but doesn't specify format (e.g., UUID), source, or constraints. This adds minimal semantic value, aligning with the baseline for low coverage without compensation.
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 ('Fetch') and resource ('a note by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'notes.list' or 'notes.search' that also retrieve notes, missing an opportunity for 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 guidance on when to use this tool versus alternatives like 'notes.list' for multiple notes or 'notes.search' for query-based retrieval. It lacks context about prerequisites (e.g., needing a valid note ID) or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-open-world, non-idempotent, and non-destructive operation, covering basic safety. The description adds context about background execution, which is useful beyond annotations, but doesn't detail performance impacts, completion time, or error handling, limiting behavioral insight.
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 ('Builds a local search index over all notes') and adds a key behavioral note ('runs in background') without any wasted words, 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.
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 (background indexing operation), annotations provide safety hints, and an output schema exists, reducing the need for return value explanation. However, the description lacks details on triggers, completion signals, or interactions with siblings, leaving gaps for effective 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 description coverage, the input schema fully documents the lack of inputs. The description doesn't need to add parameter details, so it meets the baseline for this scenario, though it could note that no configuration is required.
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 ('Builds') and target resource ('a local search index over all notes'), specifying it runs in the background. However, it doesn't explicitly differentiate from sibling tools like 'notes.index_search' or 'notes.index_status', which are related but serve different purposes (searching and checking status vs. building).
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 mentions the background execution but doesn't specify prerequisites, timing (e.g., after note updates), or exclusions compared to siblings like 'notes.index_search' or 'notes.index_status', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutable (readOnlyHint: false), non-destructive (destructiveHint: false) operation with closed-world data (openWorldHint: false). The description adds minimal behavioral context by noting the append option, but doesn't cover permissions, error conditions, or side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just one sentence that efficiently communicates the core functionality and key option. Every word earns its place, with no redundant or verbose language, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations (covering safety and data scope) and an output schema (handling return values), the description's brevity is mostly adequate. However, as a mutation tool with 0% schema coverage, it should better document the required 'id' parameter and clarify usage relative to siblings, leaving minor gaps.
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?
With 0% schema description coverage, the schema provides no parameter documentation. The description mentions 'title/body' and 'Optionally append body', which partially explains three parameters (title, body, append) but omits the required 'id' parameter entirely. This adds some value but doesn't fully compensate for the schema gap.
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 ('Update') and resource ('note') with specific fields ('title/body'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'notes.append_text' or 'notes.apply_format', 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.append_text' for appending or 'notes.create' for new notes. It mentions 'Optionally append body' but doesn't clarify when this option is appropriate, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe, read-only operation with a closed world. The description adds no behavioral context beyond this, such as pagination, sorting, or error conditions. Since annotations cover key aspects, a baseline score is appropriate, but no extra value is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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, read-only, with an output schema), the description is reasonably complete for its purpose. However, it lacks context on usage relative to siblings, which is a minor gap. The presence of an output schema means return values don't need explanation, so it's mostly adequate.
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 description coverage, the input schema fully documents the lack of parameters. The description doesn't need to add parameter details, so it meets expectations without redundancy. A score of 4 reflects that it appropriately handles this simple case.
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 ('List') and resource ('all Apple Notes folders'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'folders.contents' or 'notes.list', which might also list folders or folder contents, so it doesn't reach 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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'folders.contents' (which might list contents of a specific folder) and 'notes.list' (which might list notes), there's no indication of when this tool is preferred or what its specific scope is.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, and openWorldHint=false. The description adds context by specifying the deletion is by nested path (e.g., 'parent/child'), which clarifies how the path parameter is used, but doesn't mention permissions, error handling, or other behavioral details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Delete a folder by nested path') and includes a helpful example. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (annotations cover this), one parameter with low schema coverage (description adds some semantics), and the presence of an output schema (reducing need to describe returns), the description is mostly complete. However, it lacks usage guidelines and could benefit from more parameter details for full 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 description coverage is 0%, but the description adds meaning by explaining that the 'path' parameter is a nested path (e.g., 'parent/child'). This compensates partially, but doesn't detail format constraints or examples beyond the basic example given.
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 ('Delete') and resource ('a folder'), specifying it's by nested path. However, it doesn't explicitly differentiate from sibling tools like 'notes.delete' or 'folders.rename', 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?
No guidance is provided on when to use this tool versus alternatives like 'folders.rename' or 'notes.delete'. The description only states what it does, not when it's appropriate or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=false, indicating this is a safe read operation with deterministic results. The description adds value by mentioning filtering capabilities, but doesn't disclose important behavioral traits like pagination (implied by limit parameter), sorting order, or what happens when no filters are applied. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 ('List notes') followed by optional capabilities. Every word earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a read operation with annotations covering safety, an output schema exists (so return values are documented elsewhere), and the tool has moderate complexity, the description is reasonably complete. It covers the core purpose and filtering options, though additional context about pagination or default behaviors would be helpful.
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?
With 0% schema description coverage, the schema provides no parameter documentation. The description mentions 'filtered by folder or query', which partially explains folderId and query parameters, but doesn't address the limit parameter at all. It adds some semantic meaning but doesn't fully compensate for the schema coverage gap.
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 'List' and resource 'notes', specifying optional filtering by folder or query. It distinguishes from siblings like 'notes.get' (single note) and 'notes.search' (full-text search), but doesn't explicitly differentiate from 'notes.list_folders' which lists folders rather than notes.
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 'optionally filtered by folder or query', suggesting this tool is for retrieving notes with basic filtering. However, it doesn't explicitly state when to use this versus alternatives like 'notes.search' (which likely supports more complex queries) or 'notes.list_folders' (which lists folders). No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe read operation with limited results. The description adds useful behavioral context about performance tradeoffs (name vs body search speed) and implies a search functionality, but doesn't mention pagination, sorting, or result format details that would be helpful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise - just one sentence with zero waste. Front-loaded with the core purpose, and every word earns its place by providing specific, actionable information about search fields and performance characteristics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations covering safety (readOnlyHint) and result scope (openWorldHint=false), plus an output schema exists, the description provides adequate context for a search tool. It covers the core functionality and key behavioral insight (performance tradeoff), though additional guidance on when to use vs siblings 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?
With 0% schema description coverage, the schema provides no parameter documentation. The description mentions 'by name' and 'by body' which partially explains the 'inBody' parameter's purpose, but doesn't clarify 'query' (what format?) or 'limit' (default behavior?). It adds some meaning but doesn't fully compensate for the schema coverage gap.
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 searchable fields (name and body). It distinguishes from siblings like 'notes.get' (retrieve single) and 'notes.list' (list all), but doesn't explicitly differentiate from 'notes.index_search' which appears to be a more advanced search option.
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 when to use it by mentioning performance characteristics ('fast' vs 'slower'), suggesting name searches for speed and body searches for comprehensiveness. However, it doesn't explicitly state when to choose this over alternatives like 'notes.index_search' or 'notes.list', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds context about the 'fast' performance and dependency on index_build, which is useful behavioral information not in the annotations. However, it doesn't detail rate limits, error conditions, or output format.
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 with two short sentences that are front-loaded and waste no words. Every part ('Fast search', 'using the local index', 'run index_build first') adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 (search with index dependency), annotations cover safety aspects, and an output schema exists (so return values are documented elsewhere), the description is reasonably complete. It explains the core purpose and prerequisite, though it could better differentiate from siblings and detail parameter usage.
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 0%, so the schema provides no parameter descriptions. The description mentions no parameters, failing to explain what 'query' or 'limit' mean. Baseline is 3 since the schema covers the structure, but the description adds no semantic value to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('local index'), specifying it's a 'fast search' operation. It distinguishes from the generic 'notes.search' sibling by mentioning the index-based approach, though it doesn't fully explain how it differs in functionality or results.
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 explicit guidance to 'run index_build first', indicating a prerequisite. It implies when to use this tool (for fast search) versus alternatives, though it doesn't explicitly name when to use the regular 'notes.search' or other search-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds value by specifying what information is included ('safe mode flag'), but does not disclose additional behavioral traits like response format or error conditions.
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 is front-loaded with the core purpose. It contains no wasted words and is appropriately sized for a simple, parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, rich annotations (readOnlyHint, openWorldHint, idempotentHint), and an output schema exists, the description is complete enough. It specifies what data is retrieved, and the output schema will handle return values, so no further detail is required.
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?
There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable given the lack of parameters, warranting a baseline score above 3.
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 action ('Get') and the resource ('server status'), specifying it includes the 'safe mode flag'. It distinguishes from its only sibling tool 'server.set_safe_mode' by being a read operation versus a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'safe mode flag', which relates to the sibling 'server.set_safe_mode'. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, though the context is clear given the tool's simple purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide hints (idempotent, non-destructive, non-readOnly), and the description adds valuable context beyond these: it clarifies that the tool ensures existence (implying creation if missing) and specifies the path format with examples. No contradiction with annotations, and it enhances understanding of 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 is front-loaded with the core purpose and includes illustrative examples. Every word earns its place, with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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, rich annotations (idempotent, non-destructive), and the presence of an output schema, the description is complete enough. It covers the tool's purpose, parameter usage, and behavioral context without needing to detail return values, which are handled by the output schema.
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% schema description coverage and 1 parameter, the description compensates by explaining the 'path' parameter's purpose and providing examples ('mcp' or 'parent/child'), which adds meaning beyond the bare schema. It effectively clarifies the parameter's role in the tool's function.
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 ('ensure a folder path exists') and the resource ('folder'), with examples ('mcp' or 'parent/child') that illustrate the scope. It distinguishes from siblings like folders.delete (destructive) and folders.contents (read-only) by emphasizing creation/verification.
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 creating or verifying folder paths, providing clear context. However, it does not explicitly state when not to use it (e.g., vs. folders.rename for moving) or name alternatives, though the context of sibling tools suggests differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-open-world, and idempotent behavior. The description adds useful context about what is checked (existence and update timestamp), which is not covered by annotations. No contradictions exist, and it provides meaningful operational insight beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 ('Check if a local search index exists') and adds necessary detail ('and when it was updated'). Every word contributes value with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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, read-only, idempotent) and the presence of an output schema (which handles return values), the description is complete. It covers the tool's purpose and scope adequately without needing to explain behavior or outputs further.
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 no parameter documentation is needed. The description appropriately focuses on the tool's purpose without redundant parameter details, aligning with the baseline for zero-parameter tools.
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 ('Check') and the resource ('local search index'), with precise scope ('exists and when it was updated'). It distinguishes from siblings like 'notes.index_build' (which creates/updates) and 'notes.index_search' (which queries).
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 context (verifying index state before search/update operations), but does not explicitly state when to use vs. alternatives like 'notes.index_search' or 'notes.index_build'. It provides clear intent but lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds crucial behavioral information beyond annotations: it clarifies that deletion 'moves to Recently Deleted' rather than being permanent. This is valuable context that annotations (destructiveHint: true) don't provide, helping the agent understand the actual effect and potential recovery options.
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 perfectly concise and front-loaded: a single sentence that immediately conveys the core action, target, mechanism, and behavioral nuance. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (annotations show destructiveHint: true), the description provides exactly what's needed: it clarifies the deletion behavior, specifies the single required parameter, and the existence of an output schema means return values don't need explanation. This is complete for a simple deletion tool.
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% schema description coverage for the single 'id' parameter, the description compensates by specifying that deletion is 'by ID', giving semantic meaning to the parameter. However, it doesn't provide format details (e.g., UUID, numeric) or validation rules that would be helpful.
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 ('Delete'), the resource ('a note'), and the mechanism ('by ID'), distinguishing it from sibling tools like notes.move or notes.update. It also adds important behavioral context about moving to 'Recently Deleted' rather than permanent deletion.
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 context by specifying 'by ID', suggesting this tool is for targeted deletion rather than bulk operations. However, it doesn't explicitly state when to use this versus alternatives like folders.delete or notes.move to trash, nor does it mention prerequisites like needing the note ID.
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-notes-mcp MCP server](https://glama.ai/mcp/servers/renatoaraujo/apple-notes-mcp/badges/card.svg)](https://glama.ai/mcp/servers/renatoaraujo/apple-notes-mcp)

Score Badge

Copy to your README.md:

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

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/renatoaraujo/apple-notes-mcp'

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