Obsidian MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Most tools have distinct purposes, such as note operations (create, read, update, delete), calendar event management, and search functions. However, some overlap exists between 'search_notes' and 'search_by_property', and between 'get_backlinks' and 'get_outgoing_links', which could cause minor confusion for agents.
Naming Consistency5/5Tool names follow a consistent verb_noun pattern throughout, such as 'create_note', 'list_notes', 'update_note', and 'search_notes'. This predictability makes it easy for agents to understand and use the toolset effectively.
Tool Count3/5With 31 tools, the count is on the high side for an Obsidian server, which may feel heavy and potentially overwhelming. While it covers many features, a more streamlined set might improve usability without sacrificing functionality.
Completeness5/5The toolset provides comprehensive coverage for Obsidian vault management, including full CRUD for notes and calendar events, advanced search capabilities, link analysis, batch operations with backup/restore, and vault statistics. No significant gaps are apparent for the domain.
Average 3/5 across 31 of 31 tools scored.
See the Tool Scores section below for per-tool breakdowns.
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.jsonto 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'finds' notes, implying a read-only operation, but doesn't specify what 'related' entails (e.g., similarity metrics, link-based), how results are ordered, or if there are rate limits. This leaves key behavioral traits unclear for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place by conveying the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values), the description's gaps in purpose clarity, usage guidelines, and parameter semantics are partially mitigated. However, for a tool with no annotations and 0% schema coverage, it should do more to explain behavior and parameters to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'a specific note' but doesn't explain the 'path' parameter (e.g., file path, note ID) or the 'limit' parameter (e.g., max number of results). It adds minimal meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find notes related to a specific note' clearly states the verb ('find') and resource ('notes'), but it's vague about what 'related' means (e.g., by content, links, tags). It distinguishes from obvious siblings like 'read_note' or 'list_notes', but not from 'get_backlinks' or 'get_outgoing_links', which might also find related notes through links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over 'get_backlinks', 'get_outgoing_links', 'search_notes', or 'get_notes_by_tag', all of which could potentially find related notes. There's no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose permissions needed, whether appending is reversible, rate limits, or how it handles errors (e.g., if the note doesn't exist). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It's appropriately sized for the tool's complexity and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, 0% schema coverage, but an output schema exists, the description is incomplete. It covers the basic purpose but lacks usage guidelines, parameter details, and behavioral context. The output schema mitigates some gaps, but overall it's minimal for a tool with siblings and operational complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only implies parameters ('content' and 'path' from context) without explaining their semantics. It doesn't clarify what 'path' refers to (e.g., file path, note ID) or 'content' format (e.g., text, markdown). Baseline is 3 due to 0% coverage, but it adds minimal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Append content to an existing note' clearly states the action (append) and resource (note), but it's vague about scope and doesn't differentiate from siblings like 'update_note' or 'batch_append_notes'. It specifies 'existing' note but lacks details on format or limitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'update_note' for modifications or 'create_note' for new notes. The description implies it's for appending to existing notes but doesn't mention prerequisites, exclusions, or sibling tools like 'batch_append_notes' for multiple operations.
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 events but lacks details on permissions required, whether events are public/private, error handling, or what 'linked' entails (e.g., bidirectional sync). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary elaboration. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks parameter semantics, behavioral context, and usage guidelines, leaving critical gaps for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'note_path' expects, how 'date' and 'time' should be formatted, or the purpose of the 'confirm' parameter. With 7 parameters undocumented in both schema and description, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('Google Calendar event linked to an Obsidian note'), making the purpose immediately understandable. It distinguishes from siblings like 'create_note' by specifying the calendar integration, though it doesn't explicitly contrast with 'update_calendar_event' or 'delete_calendar_event'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_note' for standalone notes or 'update_calendar_event' for modifying existing events. The description implies usage for creating calendar events with note links but offers no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive mutation, but the description doesn't specify if deletion is permanent, requires specific permissions, sends notifications, or has rate limits. It also doesn't explain the role of parameters like 'confirm' or 'update_note' in the deletion behavior, leaving critical operational details unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action without unnecessary words. It's appropriately sized for a simple tool, with zero waste or redundancy, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive mutation tool with 3 parameters, 0% schema coverage, no annotations, and an output schema (which might help with return values), the description is incomplete. It lacks essential details like behavioral traits, parameter explanations, and usage context, making it inadequate for safe and effective tool invocation by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate by explaining parameters. It adds no meaning beyond the schema—it doesn't clarify what 'event_id' refers to, why 'confirm' is needed, or what 'update_note' does. With 3 parameters and no schema descriptions, this leaves significant gaps in understanding how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('Google Calendar event'), making the purpose immediately understandable. It distinguishes from siblings like 'update_calendar_event' or 'get_calendar_event' by specifying deletion. However, it doesn't explicitly mention what distinguishes it from 'delete_note' (a different resource type), so it's not fully specific about 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing event_id), when not to use it (e.g., for soft deletion), or refer to siblings like 'update_calendar_event' for modifications. Without such context, the agent must infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits like whether it's read-only, if it requires authentication, rate limits, or how 'recent' is defined (e.g., by date or count). It mentions 'recent' but doesn't clarify if this is based on creation date, modification, or another criterion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase 'List recent daily notes', which is front-loaded and wastes no words. Every part of the sentence contributes to the core purpose, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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), 2 parameters with low schema coverage, and no annotations, the description is minimally adequate but incomplete. It states what the tool does but lacks details on behavior, parameter usage, and differentiation from siblings, leaving gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, so the description must compensate but adds no parameter details. It doesn't explain what 'folder' or 'limit' mean, their defaults, or how they affect the listing. Since there are parameters, the baseline is not automatically 4, and the description fails to provide meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List recent daily notes' clearly states the verb ('List') and resource ('daily notes'), but lacks specificity about what constitutes 'recent' and doesn't differentiate from sibling tools like 'list_notes' or 'get_daily_note'. It's better than a tautology but remains vague in 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_notes', 'get_daily_note', or 'search_notes'. The description implies a focus on daily notes but doesn't specify context, prerequisites, or exclusions, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists notes with filters but does not describe key behaviors such as pagination (implied by 'limit' parameter), default sorting, error handling, or whether it returns metadata or full content. This leaves significant gaps in understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List notes in the vault') and adds essential qualification ('with optional filters'). There is no wasted language, and it is appropriately sized for a basic listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is incomplete. It covers the basic purpose but lacks details on behavior, parameter usage, and differentiation from siblings. The presence of an output schema mitigates the need to describe return values, but other gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'optional filters' but does not specify what parameters are available or their meanings. With 0% schema description coverage and 3 parameters (folder, limit, recursive), the schema provides titles but no descriptions. The description adds minimal value by hinting at filtering but fails to compensate for the low schema coverage, resulting in inadequate parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'List notes in the vault with optional filters', which clearly indicates it retrieves notes with filtering capabilities. However, it does not differentiate from sibling tools like 'search_notes', 'get_notes_by_tag', or 'list_daily_notes', leaving ambiguity about when to use this specific listing tool versus others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'optional filters' but does not specify what types of filters are available or how they compare to filtering in sibling tools like 'search_notes'. There is no mention of prerequisites, exclusions, or recommended contexts for use.
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 updates or moves events but doesn't describe permissions required, whether changes are reversible, error handling (e.g., for invalid event IDs), rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('update/move a calendar event') and lists key modifiable fields. There's no wasted verbiage, but it could be slightly more structured by separating usage context from parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 8 parameters), lack of annotations, and presence of an output schema, the description is minimally adequate. It states the purpose but lacks usage guidelines, detailed parameter semantics, and behavioral context. The output schema may cover return values, but the description doesn't address mutation risks or prerequisites, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'change date, time, title, or description,' which covers only 4 of the 8 parameters (date, time, title, description), ignoring event_id, confirm, duration_minutes, and location. It doesn't explain parameter interactions, defaults, or required fields, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update/move') and resource ('calendar event'), and lists specific fields that can be modified (date, time, title, description). It distinguishes from sibling tools like 'create_calendar_event' and 'delete_calendar_event' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from 'update_note' or other update tools in terms of 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing event ID), compare to sibling tools like 'update_note' or 'update_frontmatter', or specify scenarios where this tool is preferred over others. Usage is implied through 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?
No annotations are provided, so the description carries the full burden. It mentions 'atomically' which hints at transactional behavior (all-or-nothing execution), but fails to disclose critical details like required permissions, rate limits, error handling, or what 'content' means (e.g., text formatting, metadata). For a batch mutation tool, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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 ('Append content') and key qualifiers ('multiple notes', 'atomically'), 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch mutation with 2 parameters, no annotations, but has an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for that in the description. However, for a batch operation, more context on usage, parameters, and behavioral traits would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'appends' implicitly but doesn't explain what 'NoteAppend' entails (e.g., note identifiers, content format) or the purpose of the 'confirm' parameter (e.g., safety confirmation). The description adds minimal value beyond the parameter names visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append content') and target ('multiple notes'), and specifies 'atomically' which distinguishes it from the sibling tool 'append_to_note' that likely handles single notes. However, it doesn't explicitly name the resource type (e.g., 'notes in a vault' or similar context), leaving some ambiguity about what 'notes' refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'append_to_note' (for single notes) or 'batch_update_notes' (for other batch operations). It mentions 'atomically' which implies transactional safety, but doesn't explain practical scenarios or prerequisites for using batch operations.
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 'create' implying a write operation, but doesn't disclose behavioral traits like whether it overwrites existing files, requires specific permissions, handles errors (e.g., invalid paths), or what happens on success/failure. 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/5Is 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 action and resource, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It covers the basic purpose but lacks parameter details, behavioral context, and usage guidelines. The output schema helps, but the description should do more to compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'template' and 'new note' but doesn't explain what the parameters represent (e.g., 'new_note_path' is the destination file path, 'template_path' is the source template file, 'title' is optional content). Without this, users might not understand how to provide valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'new note from a template', which is specific and actionable. It distinguishes from generic 'create_note' by specifying template-based creation, though it doesn't explicitly differentiate from all siblings like 'list_templates' or 'read_note'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_note' (for non-template creation) or 'list_templates' (to find templates). There's no mention of prerequisites, such as needing an existing template file, or context for template-based workflows.
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 action ('Create') but doesn't describe what happens on success/failure, whether the note becomes immediately available, what permissions are required, or how the 'overwrite' parameter affects behavior. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that gets straight to the point. There's no wasted language or unnecessary elaboration. It's appropriately sized for a basic creation operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values) and no annotations, the description is minimally complete for stating the core action. However, for a 4-parameter mutation tool with 0% schema coverage and no behavioral annotations, it should provide more context about parameter usage and operational behavior to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 4 parameters, the description provides no information about parameter meanings. It doesn't explain what 'path' format is expected, what 'content' should contain, how 'tags' should be structured, or when 'overwrite' should be used. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('a new note in the vault'), making the purpose immediately understandable. It distinguishes from siblings like 'append_to_note' or 'update_note' by specifying creation rather than modification. However, it doesn't explicitly differentiate from 'create_from_template' which is also a creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'create_note' over 'create_from_template' or 'append_to_note', nor does it indicate any prerequisites or contextual constraints for 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 the full burden of behavioral disclosure. It mentions the tool can 'Get or create' a daily note, implying it may perform a write operation if creation is needed, but doesn't specify permissions required, whether creation is automatic or conditional, error handling, or response format. This is a significant gap for a tool with potential mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficiently communicates the core functionality, earning a perfect score for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should cover return values), the description's main gap is in parameter semantics and behavioral transparency. However, with no annotations and 0% schema coverage, the description is incomplete for a tool that might create resources. It's minimally adequate but lacks critical details for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about the parameters (e.g., what 'date_str' format to use, what 'folder' represents, or how 'create' affects behavior). It fails to compensate for the lack of schema documentation, leaving parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get or create') and resource ('daily note for a specific date'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'list_daily_notes' or 'read_note', which is why it doesn't reach 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't clarify when to use 'get_daily_note' instead of 'list_daily_notes' or 'read_note', or mention any prerequisites or exclusions, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation, what permissions are needed, how results are returned (e.g., pagination), rate limits, or error conditions. The phrase 'search' implies read-only, but this isn't explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('search calendar events by text query or date range') contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, but has output schema), the description is incomplete. It covers the basic purpose but lacks usage guidelines, detailed parameter semantics, and behavioral context. The output schema helps mitigate some gaps in return value explanation, but overall it's minimally adequate with clear deficiencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only vaguely references parameters ('text query or date range'). It doesn't explain what 'date_from' and 'date_to' represent (e.g., format, timezone), what 'max_results' defaults to or its limits, or how 'query' interacts with date filtering. This leaves significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and resource 'calendar events', specifying the search criteria as 'by text query or date range'. This distinguishes it from other calendar-related tools like 'list_calendar_events' or 'get_calendar_event', though it doesn't explicitly mention those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_calendar_events' or 'search_notes'. It mentions search criteria but doesn't specify scenarios, prerequisites, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to describe key behaviors: whether this is a read-only operation (implied but not stated), what the output format is (though an output schema exists), whether results are paginated or limited (the 'limit' parameter suggests limiting but not described), or any performance/rate-limiting considerations. For a search tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and uses parallel structure ('content, title, tags, or all'). 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with 4 parameters) and no annotations, the description is incomplete. It covers the purpose and one parameter indirectly but lacks behavioral context, usage guidelines, and details on most parameters. The existence of an output schema reduces the need to describe return values, but other gaps remain. This is minimally adequate but with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions searchable fields (content, title, tags, or all), which maps to the 'search_type' enum parameter, adding some semantics. However, it doesn't explain the 'query', 'folder', or 'limit' parameters, leaving three of four parameters with minimal context. The baseline is 3 because it adds value for one parameter but doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and resource ('the vault'), specifying what fields can be searched (content, title, tags, or all). It distinguishes from siblings like 'list_notes' (which lists without search) and 'search_by_property' (which searches by property rather than content/title/tags). However, it doesn't explicitly mention that it searches notes specifically, though this is implied by 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'search_notes' over 'list_notes' (for listing without query), 'get_notes_by_tag' (for tag-specific retrieval), or 'search_by_property' (for property-based search). There's no context about prerequisites, performance implications, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates content, implying a mutation operation, but doesn't cover critical aspects: whether it overwrites or merges content, permissions required, error handling (e.g., if path doesn't exist), or side effects. This is a significant gap 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/5Is 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 action ('Update an existing note's content'), making it easy to parse. Every word contributes directly to the purpose, achieving optimal conciseness for such a brief statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), the description's minimalism is partially acceptable. However, as a mutation tool with no annotations and low parameter semantics, it should do more to explain behavior and usage. The description is complete enough for basic understanding but inadequate for safe, effective use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'content' but doesn't explain what 'path' is (e.g., file path, note identifier) or details like format constraints (e.g., markdown, plain text). It adds minimal value beyond the parameter names, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing note's content'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_note' (creates new) and 'append_to_note' (adds to existing), though it doesn't explicitly mention these distinctions. The description is specific but could be more precise about what 'content' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., note must exist), exclusions (e.g., cannot update non-existent notes), or comparisons to siblings like 'batch_update_notes' (for multiple notes) or 'update_frontmatter' (for metadata). Usage is implied only by the verb 'Update,' leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but lacks details on what the link graph includes (e.g., nodes, edges, format), whether it's read-only or has side effects, performance considerations, or error handling. This leaves significant gaps for a tool that likely returns complex 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/5Is 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 purpose, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely complexity (returning a link graph) and the presence of an output schema, the description is minimally adequate. It states what the tool does but lacks context on the graph's structure or use cases. The output schema should cover return values, but more behavioral context would help the agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, which is acceptable since there's only one optional parameter ('max_notes') with a default value. With 0% schema description coverage, the description doesn't need to compensate, as the parameter is straightforward and optional. The baseline for 0 parameters is 4, reflecting that no parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get[s] the link graph for the vault', which provides a clear verb ('Get') and resource ('link graph for the vault'). However, it doesn't differentiate from sibling tools like 'get_backlinks' or 'get_outgoing_links', leaving ambiguity about what distinguishes this graph from other link-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools like 'get_backlinks' or 'get_outgoing_links', leaving the agent to infer usage scenarios independently.
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 a read operation ('Get'), implying non-destructive behavior, but does not disclose any behavioral traits such as performance impact, data freshness, or authentication needs. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and appropriately sized for a simple 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, output schema exists), the description is minimally adequate. However, with no annotations and an output schema, it fails to explain what statistics are returned or any behavioral context, leaving gaps in completeness for a stats-retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add param info, which is appropriate, earning a baseline score of 4 for adequately handling the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get statistics about the vault' clearly states the verb ('Get') and resource ('vault'), but it is vague about what specific statistics are retrieved (e.g., counts, sizes, usage). It distinguishes from siblings by focusing on vault-level stats rather than notes or events, but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, timing, or comparisons to other tools (e.g., for note-level stats). The description alone offers no 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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: atomic updates (all-or-nothing), automatic backup, and rollback capability. However, it lacks details on permissions, rate limits, error handling, or what 'atomically' entails in practice, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core purpose ('Update multiple notes atomically') and adds value with behavioral context ('with automatic backup and rollback'), making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters, 0% schema coverage, no annotations, but an output schema, the description is incomplete. It covers atomicity and backup/rollback but misses parameter guidance, error details, and sibling differentiation. The output schema mitigates some gaps, but overall it's minimally adequate with clear deficiencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter-specific information. It implies 'updates' parameter usage but doesn't explain the NoteUpdate structure, 'confirm' for safety, or 'dry_run' for testing. The description fails to bridge the schema's documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update multiple notes atomically') and resource ('notes'), distinguishing it from single-note tools like 'update_note' or 'append_to_note'. However, it doesn't explicitly differentiate from 'batch_append_notes', which also handles multiple notes but for appending rather than updating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update_note' for single updates or 'batch_append_notes' for batch appends. It mentions 'automatic backup and rollback' but doesn't specify prerequisites or exclusions, 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.
- 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 retrieves details but doesn't disclose behavioral traits such as required permissions, error handling, rate limits, or what details are included in the output. This is a significant gap for a read operation with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core purpose. 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.
Completeness3/5Given 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 covers return values), low complexity (1 parameter), and no annotations, the description is minimally adequate. However, it lacks context on usage versus siblings and behavioral details, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'event_id' is used to identify a calendar event, but doesn't provide format, examples, or constraints beyond what the schema's title ('Event Id') implies. This partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('specific calendar event'), making the purpose unambiguous. It distinguishes from siblings like 'list_calendar_events' by specifying retrieval of a single event by ID, though it doesn't explicitly name 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_calendar_events' or 'search_calendar_events'. The description implies usage for retrieving a known event by ID, but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool finds notes but doesn't cover critical aspects like whether it's read-only, if it has side effects, rate limits, authentication needs, or pagination behavior. For a retrieval 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/5Is 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 and efficiently conveys the core functionality without unnecessary details, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is minimally adequate. It states the purpose but lacks behavioral details and parameter guidance. The presence of an output schema means return values are documented elsewhere, but the description should still cover usage context and limitations to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'a specific tag,' which aligns with the 'tag' parameter in the input schema. However, schema description coverage is 0%, and the description doesn't explain the 'limit' parameter or provide additional context like tag format or search scope. It adds minimal value beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find all notes with a specific tag.' It specifies the verb ('find'), resource ('notes'), and filtering criterion ('with a specific tag'). However, it doesn't explicitly differentiate from sibling tools like 'search_notes' or 'list_notes,' which may also involve note retrieval, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_notes' or 'list_notes,' nor does it specify scenarios where tag-based filtering is preferred over other methods. This lack of context leaves the agent without clear usage instructions.
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 a read operation ('Get'), implying non-destructive behavior, but doesn't disclose permissions, rate limits, output format, or error handling. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core purpose, zero waste. Efficiently conveys the essential action without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, but an output schema exists, the description is minimally adequate. It covers the basic purpose but lacks behavioral details and parameter guidance, leaving gaps for a tool with one required parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'from a note' which hints at the 'path' parameter referring to a note, but doesn't specify format (e.g., file path, note title) or constraints. This adds minimal meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all links from a note to other notes'), specifying outgoing links. It distinguishes from sibling 'get_backlinks' by directionality, though not explicitly named. It's not fully specific about scope (e.g., format or depth), keeping it at 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_backlinks' (for incoming links) or 'get_link_graph' (for broader link analysis). The description implies usage for outgoing links only, but lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic action without describing what 'available' means, whether results are paginated, sorted, or filtered, what authentication is required, or what the output format looks like. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, front-loading the essential action and resource. There's zero wasted language or redundancy, making it maximally efficient while still communicating the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and only one simple parameter, the description's minimalism is somewhat acceptable. However, for a data listing operation with no annotations, it should ideally provide more context about what constitutes 'available' backups and how results are presented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the schema has one parameter ('limit') with 0% description coverage. Since the schema provides the parameter definition but no semantic context, and the description adds nothing about parameters, this meets the baseline for minimal parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('available batch backups'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'restore_batch_backup' or explain what distinguishes batch backups from other backup types 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'restore_batch_backup' or other list operations. There's no mention of prerequisites, typical use cases, or when this specific listing function is appropriate versus other data retrieval methods.
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 action ('List upcoming') but doesn't mention authentication requirements, rate limits, pagination behavior, error conditions, or what 'upcoming' means relative to current time. For a read operation with zero annotation coverage, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (listing with filtering), no annotations, and an output schema that presumably covers return values, the description is minimally adequate. It states what the tool does but lacks important context about behavior, parameters, and differentiation from siblings. The existence of an output schema prevents this from being a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so parameters are only documented by their titles and types. The description doesn't mention either parameter, providing no additional semantic meaning beyond what's in the schema. However, with only 2 parameters and default values provided in the schema, the baseline is 3 as the schema provides basic documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('Google Calendar events') with a qualifier ('upcoming'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'search_calendar_events', which could serve a similar purpose with different filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_calendar_events' or 'get_calendar_event'. It lacks any context about prerequisites, appropriate scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states it 'lists' templates, implying a read-only operation, but doesn't cover critical aspects like whether it requires authentication, returns paginated results, includes metadata (e.g., template names or descriptions), or how it interacts with the 'folder' parameter. For a tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste: 'List available note templates'. It's front-loaded with the core action and resource, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it lacks context on behavioral traits and usage scenarios, making it just sufficient but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what the input schema provides. With 0% schema description coverage and one parameter ('folder'), the schema alone defines it as a string with default 'Templates'. The description doesn't explain what 'folder' means (e.g., a directory path, a category) or its effect, so it doesn't compensate for the low coverage, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available note templates' clearly states the action (list) and resource (note templates), making the purpose immediately understandable. However, it doesn't distinguish this tool from other list-like siblings such as 'list_notes', 'list_all_tags', or 'list_calendar_events', which would require specifying what makes templates unique (e.g., predefined note structures).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_notes' and 'create_from_template', there's no indication whether this is for browsing templates before creation, checking what's available, or other contexts. The lack of when/when-not statements leaves usage 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, the description carries the full burden of behavioral disclosure. It mentions 'restore' and 'undo,' implying a write operation, but doesn't specify permissions needed, whether it's destructive, rate limits, or what happens to current notes. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loaded with the tool's purpose. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations), the description is incomplete—it lacks details on behavior, parameters, and output. However, an output schema exists, so return values are covered elsewhere, preventing a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters, and schema coverage is 0%, leaving the single parameter 'backup_id' undocumented. However, with only one parameter, the baseline is 4, but the description fails to compensate for the lack of schema info, so it's scored lower for not adding any meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('restore') and resource ('notes from a batch backup'), specifying it's for undoing batch operations. However, it doesn't differentiate from potential sibling tools like 'list_batch_backups' or explain what a 'batch backup' entails, keeping it from 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for undoing batch operations but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'list_batch_backups' to see available backups, 'batch_update_notes' for batch changes). It lacks prerequisites or exclusions, offering minimal context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether it's read-only, pagination behavior, rate limits, authentication needs, or what happens with partial matches. The presence of an output schema helps but isn't mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and uses parentheses for clarification without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters, 0% schema coverage, and no annotations, the description is minimal. The output schema existence reduces need to explain returns, but more context on usage, parameters, and behavior would improve completeness. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only mentions 'frontmatter property (metadata field)', which loosely relates to 'property_name'. It doesn't explain the three parameters (property_name, property_value, limit), their formats, or interactions. Baseline 3 is appropriate as it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and resource ('notes'), specifying the search criteria ('by frontmatter property/metadata field'). It distinguishes from generic 'search_notes' by focusing on frontmatter properties, but doesn't explicitly differentiate from other property-related tools like 'update_frontmatter'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_notes', 'get_notes_by_tag', or 'update_frontmatter'. The description implies it's for searching by metadata fields, but doesn't specify scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions 'preserves content' which is useful behavioral context, but doesn't address permissions needed, whether changes are reversible, error conditions, or what the output contains. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. Every word contributes: 'Update' (action), 'frontmatter fields' (scope), 'in a note' (target), 'preserves content' (behavioral detail). Perfectly front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no annotations, but with an output schema present, the description provides basic purpose and one behavioral detail. It's minimally adequate for understanding what the tool does, but lacks guidance, full parameter context, and comprehensive behavioral disclosure expected for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds context that parameters update 'frontmatter fields' and that content is preserved, giving meaning to what the parameters affect. However, it doesn't explain parameter formats, constraints, or examples beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update frontmatter fields') and target ('in a note'), with the specific detail that it 'preserves content'. It distinguishes from generic 'update_note' by focusing on frontmatter fields specifically, though it doesn't explicitly contrast with all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'update_note' or 'batch_update_notes'. The description implies it's for frontmatter updates, but doesn't specify prerequisites, constraints, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'usage counts' which adds some behavioral context, it doesn't address important aspects like whether this is a read-only operation, potential performance considerations for large vaults, pagination behavior, or what format the output takes. For a tool with no 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/5Is 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 front-loaded with the essential information and doesn't include unnecessary elaboration. Every word earns its place in this concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and only one parameter with a default, the description is minimally adequate. However, it doesn't provide enough behavioral context for a tool with no annotations. The mention of 'usage counts' adds some value, but more context about the operation's characteristics would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 1 parameter and 0% schema description coverage, the description doesn't mention the 'limit' parameter at all. However, since there's only one parameter and it has a default value, the impact is reduced. The description focuses on what the tool returns rather than its inputs, which is reasonable for a simple list operation. A baseline of 4 is appropriate for a tool with zero parameters mentioned but only one actual parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all tags in the vault') along with additional context about 'usage counts'. It distinguishes from sibling tools like 'get_notes_by_tag' which filters notes by tag rather than listing tags themselves. However, it doesn't explicitly differentiate from all possible tag-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when this tool is appropriate versus other tag-related operations or list operations. The sibling tools include 'get_notes_by_tag' which has a related but different purpose, but the description doesn't help the agent choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that deletion typically moves notes to .trash unless 'permanent' is set, which is useful context about the tool's default safety behavior. However, it lacks details on permissions, error handling, or what the output schema might return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that efficiently conveys the core action and a key behavioral detail (default trash behavior). Every word earns its place, with no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and no annotations, the description is moderately complete. It covers the basic purpose and a critical behavioral trait, but as a mutation tool with 2 parameters, it should ideally include more about usage context or parameter details to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies the 'permanent' parameter's effect (default false means moves to trash), adding meaning beyond the schema. However, it doesn't explain the 'path' parameter or provide full parameter context, leaving gaps in documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a note'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from other deletion tools (like 'delete_calendar_event') beyond mentioning notes, which keeps it from 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'delete_calendar_event' or other note-related tools. It mentions the default behavior (moves to .trash), but doesn't specify scenarios or prerequisites for use, leaving usage context vague.
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 ('Read') but doesn't cover important aspects like permissions needed, error handling, or what happens if the note doesn't exist. This is a significant gap for a tool that likely interacts with a data vault.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple read operation, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is reasonably complete. It covers the basic action and resource, though it could benefit from more behavioral context, especially since no annotations are provided to fill in gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that the 'path' parameter refers to a note in the vault, which clarifies beyond the schema's generic 'Path' title. With 0% schema description coverage and only one parameter, this compensates adequately, though it could provide more detail on path format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read') and resource ('full content of a note from the vault'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_note' or 'search_notes', which might have overlapping functionality, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_notes' or 'search_notes'. It lacks context about prerequisites or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic function without mentioning permissions, rate limits, pagination, or response format. For a read operation with no annotation coverage, this is insufficient to inform the agent about key 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core purpose. Every word earns its place, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It states the purpose clearly but lacks details on parameters, behavioral context, or usage nuances. The presence of an output schema reduces the need to explain return values, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not mention any parameters, leaving both 'path' and 'limit' unexplained. The baseline is 3 because the schema provides full structure, but the description adds no semantic meaning beyond what the schema already defines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get all notes that link to') and resource ('a specific note'), explicitly distinguishing it from sibling tools like 'get_outgoing_links' by specifying 'incoming links' in parentheses. This provides precise differentiation from related tools in the server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'incoming links,' which suggests when to use this tool versus alternatives like 'get_outgoing_links.' However, it lacks explicit guidance on when not to use it or comparisons with other tools like 'get_related_otes' or 'get_link_graph,' leaving some ambiguity.
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 what the tool does but omits critical details such as whether this is a read-only operation, how results are ordered, if pagination is supported, or what happens when limit is exceeded. For a tool with output schema, some behavior is implied, but key operational traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It is front-loaded with the core purpose and avoids unnecessary elaboration, making it easy for an agent to parse quickly. Every word earns its place by directly contributing to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (finding orphaned notes), no annotations, and an output schema that likely covers return values, the description is minimally adequate. It states the purpose clearly but lacks context on behavior, usage scenarios, or limitations. The presence of an output schema reduces the need to explain returns, but more operational guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond the input schema, which has 0% description coverage. However, with only one parameter (limit) and a default value of 50, the schema is minimal and self-explanatory. The description does not need to compensate heavily, but it could have clarified the limit's effect (e.g., on performance or result truncation). Baseline is 4 due to low parameter complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find') and target resource ('notes with no incoming or outgoing links'), which distinguishes it from sibling tools like get_backlinks, get_outgoing_links, or get_related_notes that focus on linked notes. It precisely defines the scope of orphaned notes without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_notes, search_notes, or get_notes_by_tag. It does not mention prerequisites, exclusions, or typical use cases, leaving the agent to infer usage context 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.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/getglad/obsidian_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server