Flint Note
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between search_notes, search_notes_advanced, and search_notes_sql, which could cause confusion about which to use for different search scenarios. The descriptions help clarify, but the boundaries are not perfectly clear.
Naming Consistency5/5Tool names follow a consistent verb_noun pattern throughout, with clear and predictable naming (e.g., create_note, delete_note, get_note, update_note). There are no deviations in style or convention, making it easy to understand the action and target.
Tool Count3/5With 28 tools, the count feels heavy for a note-taking domain, bordering on excessive. While the tools cover many aspects, it may overwhelm agents and could likely be consolidated without losing functionality.
Completeness5/5The tool set provides comprehensive coverage for note management, including CRUD operations for notes, note types, and vaults, as well as advanced features like linking, search, and migration. There are no obvious gaps, and agents can handle full lifecycles without dead ends.
Average 3.1/5 across 28 of 28 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.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?
With no annotations, the description carries full burden but provides minimal behavioral context. It doesn't disclose permission requirements, whether creation is idempotent, what happens with invalid types/metadata, or how errors are handled. 'Create' implies mutation but lacks safety/constraint details needed for a tool with 6 parameters.
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?
Single sentence is appropriately concise for a creation tool. However, it's not optimally front-loaded - it could immediately distinguish single vs batch creation patterns. No wasted words, but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the single vs batch creation dichotomy evident in the schema, doesn't clarify what 'note types' are or how to discover them, and provides no information about return values or error conditions.
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 100%, so the schema fully documents all 6 parameters. The description adds no parameter-specific information beyond implying 'type' matters and batch creation is possible. Baseline 3 is appropriate when schema does all 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 action ('create') and resource ('notes') but is vague about scope - 'one or more notes of the specified type(s)' doesn't clarify whether this handles single vs batch creation or what 'type' means. It distinguishes from deletion/search siblings but not clearly from other creation tools like create_note_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?
No guidance on when to use this tool vs alternatives like create_note_type or update_note. The description mentions 'specified type(s)' but doesn't explain what types are or when batch vs single creation is appropriate. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose critical traits like whether deletions are permanent/irreversible, require specific permissions, have rate limits, or provide confirmation feedback. For a destructive bulk operation, this lack of transparency 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 wasted words. It front-loads the core action ('Delete multiple notes') and immediately clarifies the scope ('matching criteria'), 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 destructive bulk operation with no annotations and no output schema, the description is inadequate. It lacks context on safety (e.g., confirmation workflow), side effects, error handling, or return values. Given the complexity and risk, more completeness is needed to guide safe usage.
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 100%, so parameters are fully documented in the schema. The description adds no additional meaning about parameters beyond implying they define 'criteria' for filtering. This meets the baseline for high schema coverage but doesn't enhance understanding (e.g., explaining how criteria combine).
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 multiple notes') and the scope ('matching criteria'), which distinguishes it from the sibling 'delete_note' that likely handles single deletions. However, it doesn't specify what constitutes 'multiple' (e.g., all matching vs. batch limits) or mention the resource type (e.g., Obsidian notes), making it slightly less specific than ideal.
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 'delete_note' for single deletions or 'search_notes' for previewing matches. The description implies it's for bulk operations but doesn't clarify prerequisites (e.g., needing to confirm matches first) or exclusions (e.g., not for archived notes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states it 'creates' a new note type, implying a write/mutation operation, but doesn't disclose permissions required, whether the operation is idempotent, what happens on conflicts (e.g., duplicate type_name), or the response format. For a creation 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, efficient sentence that front-loads the core action ('Create a new note type') and lists key components. Every word earns its place 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 tool's complexity (creation operation with nested objects, 5 parameters) and lack of both annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, idempotency, or response format, nor does it provide usage guidance. For a tool that creates structured data types, more context is needed for safe and effective use.
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 100%, so the schema already documents all 5 parameters thoroughly. The description mentions 'description, agent instructions, and metadata schema', which aligns with parameters but adds no additional meaning beyond what the schema provides (e.g., no examples, format details, or constraints). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 'note type', specifying it creates a new note type with description, agent instructions, and metadata schema. It distinguishes from siblings like 'create_note' (creates notes, not note types) and 'update_note_type' (updates existing note types). However, it doesn't explicitly differentiate from all siblings like 'list_note_types' or 'delete_note_type' in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a vault), when not to use it (e.g., for updating existing note types), or direct alternatives like 'update_note_type' for modifications. The agent must infer usage from the tool name and sibling list 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 full burden. It states the deletion is 'permanent', which is crucial behavioral context. However, it doesn't mention permissions required, error conditions, what happens to linked data, or confirmation workflow details beyond the schema's 'confirm' parameter.
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's front-loaded with the core action and includes the critical 'permanently' qualifier. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is inadequate. It should explain more about the confirmation workflow, what 'permanently' entails, potential side effects on linked notes, and error scenarios. The current description leaves too many behavioral questions unanswered.
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 100%, so the schema fully documents all three parameters. The description adds no additional parameter semantics beyond what's in the schema descriptions. Baseline 3 is appropriate when schema does all the parameter documentation work.
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 ('an existing note'), specifying it's a permanent deletion. It distinguishes from 'bulk_delete_notes' by being singular, but doesn't explicitly differentiate from other deletion tools like 'delete_note_type' or 'remove_vault'.
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 'bulk_delete_notes' for multiple deletions or 'rename_note' for non-destructive changes. It mentions 'permanently' which hints at irreversibility, but offers no explicit usage context or prerequisites.
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 that deletion can optionally handle existing notes, hinting at destructive behavior, but fails to specify critical details like permissions required, whether the action is reversible, error handling for invalid inputs, or what happens to associated data beyond notes. This is inadequate for a mutation tool with potential data loss.
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 ('Delete a note type') and adds a useful qualifier ('and optionally handle existing notes'). There's no wasted verbiage, though it could be slightly more structured by separating key points.
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 tool's complexity (a destructive mutation with 4 parameters and no output schema) and lack of annotations, the description is insufficient. It doesn't cover behavioral nuances like confirmation requirements, migration specifics, or error scenarios, leaving significant gaps for an agent to operate safely and effectively.
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 100%, so the schema fully documents all parameters. The description adds minimal value by implying the 'action' parameter relates to handling existing notes, but it doesn't explain the semantics or consequences of choices like 'migrate' versus 'delete' beyond what's in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a note type') and resource ('note type'), which is specific and unambiguous. However, it doesn't explicitly distinguish this tool from sibling tools like 'delete_note' or 'bulk_delete_notes' beyond mentioning 'note type' versus '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 such as 'delete_note' or 'bulk_delete_notes'. It mentions handling existing notes but doesn't clarify prerequisites, dependencies, or typical use cases, leaving the agent to infer usage from context 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 describes a read operation ('Get'), which implies it's non-destructive, but doesn't specify permissions, rate limits, return format, or pagination behavior. This leaves significant gaps for an agent to understand how to interact with the tool effectively.
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 that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficiently conveys the core functionality, making it easy to parse and understand 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of notes, their details, or just identifiers), nor does it cover behavioral aspects like error handling or performance considerations. For a tool with one parameter but no structured output information, more context is needed.
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 100% description coverage, with the 'identifier' parameter documented as 'Note identifier (type/filename format)'. The description adds no additional meaning beyond this, as it doesn't elaborate on the parameter's usage or constraints. The baseline score of 3 is appropriate since the schema handles the parameter documentation adequately.
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 notes that link to the specified note'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_note_links' or 'search_by_links', 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 'get_note_links' or 'search_by_links', nor does it mention any prerequisites or exclusions. It merely states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a note but does not describe what 'retrieve' includes (e.g., content, metadata, formatting), potential errors (e.g., if the note doesn't exist), authentication needs, rate limits, or response format. For a read operation 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, efficient sentence that front-loads the core purpose ('Retrieve a specific note by identifier') with zero wasted words. It directly communicates the essential action without redundancy or unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a retrieval tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It does not explain what is retrieved (e.g., note content, metadata, or both), handle error cases, or provide context on sibling tools. This leaves significant gaps for an agent to understand the tool's full behavior and usage context.
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 100%, so the schema already documents all three parameters (identifier, vault_id, fields) with clear descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as examples of identifier formats or field usage. However, it implies retrieval by identifier, which aligns with the schema, earning the baseline score for high 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 ('Retrieve') and resource ('a specific note'), making the purpose unambiguous. It distinguishes from siblings like 'get_notes' (plural retrieval) and 'get_note_info' (metadata retrieval) by specifying retrieval by identifier. However, it doesn't explicitly mention what 'retrieve' entails (e.g., content, metadata, or both), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 many sibling tools like 'get_note_info', 'get_note_links', 'search_notes', and 'list_notes_by_type', there is no indication of which tool is appropriate for different scenarios (e.g., retrieving full content vs. metadata vs. links). This lack of differentiation leaves the agent to guess based on tool names 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 full burden for behavioral disclosure but only states the basic action. It doesn't mention whether this is a read-only operation, what happens with invalid identifiers, whether there are rate limits, authentication requirements, or what format the response takes. For a tool with 3 parameters and no output schema, 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 a single, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a straightforward retrieval 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'retrieve' actually returns (full note content? metadata only?), how errors are handled, or provide context about the note system. For a batch operation tool in a complex ecosystem with many siblings, more guidance is needed.
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 100%, so all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema descriptions (format details for identifiers, optional vault_id behavior, fields wildcard patterns). This meets the baseline expectation when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'multiple notes by their identifiers', making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'get_note' (singular) or 'list_notes_by_type', leaving room for potential confusion about when to use this batch retrieval versus other listing/searching tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (get_note, list_notes_by_type, search_notes, etc.), there's no indication whether this is for batch retrieval of known identifiers versus searching for unknown notes or listing by criteria. The agent must 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. It mentions 'List all notes' but doesn't disclose behavioral traits like pagination (implied by 'limit' parameter), whether results are sorted, if it's read-only (implied but not stated), performance characteristics, or error handling. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words. However, it could be slightly more structured by explicitly separating purpose from output details (e.g., 'Lists all notes filtered by type. Returns results with filename 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 no annotations, no output schema, and 3 parameters with full schema coverage, the description is minimally adequate. It covers the basic action and output scope ('filename information'), but lacks details on return format, error cases, or performance. For a list tool with siblings offering similar filtering, more context on differentiation would improve 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 100%, so the schema fully documents parameters ('type', 'limit', 'vault_id'). The description adds no additional meaning about parameters beyond implying type filtering and filename inclusion. It doesn't explain what 'filename information' entails or provide examples of valid note types. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 ('notes of a specific type'), and specifies the inclusion of 'filename information'. It distinguishes from generic listing tools like 'get_notes' by focusing on type filtering. However, it doesn't explicitly differentiate from 'search_notes' or 'search_notes_advanced' which might also filter by 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 like 'get_notes', 'search_notes', or 'search_notes_advanced'. It mentions 'type' filtering but doesn't clarify if this is the primary method for type-based queries or if other tools offer overlapping functionality. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Scan all existing notes' and 'one-time migration,' hinting at a potentially resource-intensive or irreversible operation, but fails to specify critical details like whether it's read-only, destructive, requires specific permissions, has side effects, or how it handles errors. This leaves significant gaps for a tool that likely modifies 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, efficient sentence that front-loads the key action and purpose without unnecessary words. Every part ('Scan all existing notes,' 'populate the link tables,' 'one-time migration') earns its place by conveying essential information concisely.
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 tool's complexity (likely a data migration operation), lack of annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like safety, performance impact, or return values, leaving the agent with incomplete context for proper invocation. This is inadequate for a tool that could have significant side effects.
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 100% description coverage for its single parameter ('force'), so the schema fully documents the parameter. The description does not add any additional meaning beyond what the schema provides (e.g., it doesn't explain the implications of forcing migration). Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to.
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 ('Scan all existing notes and populate the link tables') and purpose ('one-time migration'), specifying the verb and resource. It distinguishes from siblings like 'find_broken_links' or 'get_note_links' by focusing on migration rather than querying, 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?
The description implies usage as a 'one-time migration' tool, suggesting it's for initial setup or maintenance, but provides no explicit guidance on when to use it versus alternatives (e.g., when to choose this over 'find_broken_links' for link-related tasks) or any prerequisites. It lacks clear exclusions or context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It doesn't specify whether this is a read-only operation, what permissions might be required, how results are returned (e.g., pagination, format), or any rate limits. The description only states the basic function without behavioral details.
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 directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters and no output schema, the description is inadequate. It doesn't explain what the tool returns (e.g., note objects, links, counts), how results are structured, or any limitations. With no annotations and incomplete behavioral context, this leaves significant gaps for an AI agent to understand the tool's full behavior.
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 100%, so the schema already fully documents all four parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples, edge cases, or usage patterns). This meets the baseline of 3 when schema coverage is high.
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') with the specific criteria ('based on their link relationships'), which distinguishes it from generic search tools. However, it doesn't explicitly differentiate from sibling tools like 'get_note_links' or 'find_broken_links' that also deal with link relationships.
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_notes', 'search_notes_advanced', or 'find_broken_links'. There's no mention of prerequisites, context, or comparative advantages/disadvantages with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'advanced search' but fails to describe critical behaviors such as pagination (implied by limit/offset parameters but not explained), rate limits, authentication needs, error handling, or what the search returns (e.g., result format, default fields). This leaves significant gaps for a tool with 12 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information ('Advanced search with structured filters') without unnecessary words. Every part of the sentence earns its place by specifying the tool's core functionality, 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no annotations, no output schema), the description is insufficient. It lacks details on behavioral traits (e.g., search performance, result limits), usage context (e.g., when to choose over siblings), and output expectations. For a search tool with many options, this leaves the agent under-informed about how to effectively invoke it.
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 100%, so the schema already documents all 12 parameters thoroughly. The description adds minimal value by hinting at filter types ('metadata, dates, and content'), but it doesn't provide additional context like parameter interactions, default behaviors, or examples beyond what the schema specifies. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Advanced search with structured filters for metadata, dates, and content,' which specifies the verb (search), resource (notes), and scope (advanced with structured filters). It distinguishes itself from simpler search tools like 'search_notes' but doesn't explicitly differentiate from 'search_notes_sql' or 'search_by_links' among 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 'search_notes' (simpler search), 'search_notes_sql' (SQL-based), or 'search_by_links' (link-focused). It mentions 'advanced search' but doesn't clarify specific use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. 'Switch to' implies a state change operation, but the description doesn't reveal whether this affects subsequent operations, requires specific permissions, or has any side effects. It's minimal 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's appropriately sized for a simple operation and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'switching' entails operationally, what happens after switching, or how this interacts with other tools in the vault management context.
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 100%, so the schema already documents the single 'id' parameter fully. The description adds no additional parameter context beyond what's in the schema, meeting the baseline for high 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 action ('switch to') and resource ('vault'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'get_current_vault' or 'list_vaults', but the verb 'switch' implies changing state rather than retrieving information.
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 'get_current_vault' or 'list_vaults'. There's no mention of prerequisites (e.g., needing to know vault IDs from 'list_vaults') or consequences of switching vaults.
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 ('update') without disclosing critical behavioral traits. It doesn't mention that this is a mutation operation, potential side effects (e.g., overwriting content), authentication needs, error handling, or that it supports optimistic locking via content_hash—leaving significant gaps for an agent to understand tool 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 a single, efficient sentence with zero wasted words—'Update one or more existing notes'—making it front-loaded and easy to parse. Every word earns its place by conveying the core action and scope.
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 tool's complexity (mutation with 6 parameters, nested objects, no output schema, and no annotations), the description is inadequate. It lacks details on return values, error conditions, batch processing implications, or how it interacts with sibling tools, leaving the agent under-informed for safe and effective use.
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 100%, so the schema fully documents all 6 parameters and their purposes (e.g., identifier format, content_hash for optimistic locking, batch vs. single updates). The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline score of 3 for high 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 action ('update') and resource ('existing notes'), and specifies it can handle 'one or more' notes, which distinguishes it from single-note operations. However, it doesn't explicitly differentiate from sibling tools like 'rename_note' or 'update_note_type' that might also modify notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 'rename_note' or 'update_note_type', nor does it mention prerequisites such as needing note identifiers or content hashes. It lacks context about batch vs. single updates, leaving the agent to infer usage from the schema 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. It implies a mutation ('update') but lacks critical behavioral details: it doesn't specify if changes are reversible, what permissions are required, whether it's idempotent, or how conflicts are handled (though 'content_hash' in schema hints at conflict prevention). The description adds minimal value beyond the basic action, leaving significant 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 that front-loads the core action ('update') and resource ('note type'), with no wasted words. It clearly communicates the scope ('one or more fields') and target ('existing'), 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 6 parameters, no annotations, and no output schema, the description is insufficient. It lacks behavioral context (e.g., side effects, error handling), usage prerequisites, and output expectations. While the schema covers parameters well, the description doesn't compensate for missing annotations or output details, leaving the agent under-informed for safe invocation.
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 100%, so parameters are well-documented in the schema. The description adds no specific parameter semantics beyond implying fields can be updated partially ('one or more fields'), which is already suggested by the schema's optional properties. It doesn't explain parameter interactions or usage nuances, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('update') and resource ('existing note type'), specifying it can modify 'one or more fields'. It distinguishes from sibling tools like 'create_note_type' (creation vs. update) and 'update_note' (note vs. note type). However, it doesn't explicitly differentiate from 'update_vault' or other update operations beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., note type must exist), exclusions (e.g., cannot update certain fields), or comparisons with siblings like 'create_note_type' for new types or 'update_note' for note content. The description only states what it does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is an update operation, implying mutation, but doesn't disclose behavioral traits such as required permissions, whether changes are reversible, error conditions (e.g., invalid ID), or side effects. 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 directly specifies the modifiable fields, 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 no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., permissions, errors), usage context, and expected outcomes, leaving significant gaps for an AI agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters (id, name, description). The description adds minimal value by listing updatable fields ('name or description'), but doesn't provide additional context like format constraints or examples beyond what the schema already documents.
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 ('vault information'), specifying what fields can be modified ('name or description'). It distinguishes from siblings like 'create_vault' (creation) and 'remove_vault' (deletion), but doesn't explicitly differentiate from other update tools like 'update_note' or 'update_note_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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing vault ID), exclusions (e.g., what happens if only one field is provided), or comparisons to similar tools like 'update_note' for different resources.
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 retrieves information, implying a read-only operation, but doesn't specify what information is returned (e.g., vault name, path, settings), whether it requires authentication, or if there are rate limits. The description is minimal and lacks behavioral details beyond the basic action.
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 that is front-loaded with the tool's purpose. It wastes no words and efficiently communicates the core function without unnecessary elaboration, making it easy to parse and understand 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 tool's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'information' includes (e.g., metadata, status), how it relates to siblings like 'list_vaults', or any behavioral traits. For a tool in a context with many sibling tools, more context is needed to ensure proper usage.
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 the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it naturally compensates by focusing on the tool's purpose. With no parameters, the baseline is high as there's nothing to document 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 ('Get') and resource ('information about the currently active vault'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'list_vaults' or 'get_note_info', which reduces specificity. The description avoids tautology by not merely restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'list_vaults' (which lists all vaults) or 'get_vault' (if it existed), nor does it specify prerequisites such as needing an active vault. Usage is implied by the phrase 'currently active vault,' but no explicit when/when-not instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'detailed information' and 'filename for link creation', but doesn't disclose behavioral traits like whether it's read-only (implied by 'get'), error handling, performance, or output format. For a tool with no annotation coverage, this leaves significant gaps in understanding how it 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?
Single sentence, front-loaded with core purpose, and efficiently includes key detail about filename. No wasted words; every part earns its place. Structure is clear and 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 no annotations, no output schema, and 3 parameters with full schema coverage, the description is minimally adequate. It states the purpose and a key output aspect (filename), but lacks details on behavior, error cases, or when to use vs. siblings. For a read operation in a complex sibling set, it should provide more context to be fully helpful.
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 100%, so parameters are fully documented in the schema. The description adds no specific parameter semantics beyond implying 'title_or_filename' is used for lookup and 'filename' is included in output. It doesn't explain parameter interactions or provide extra context, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('about a note'), specifying it includes 'filename for link creation'. It distinguishes from siblings like 'get_note' (likely simpler) and 'get_notes' (list vs. detail), but doesn't explicitly name alternatives. Purpose is specific but could better differentiate from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like 'get_note' or 'search_notes'. The description implies it's for detailed info including filenames, but doesn't state prerequisites, exclusions, or compare to siblings. Usage is implied from purpose alone, lacking explicit 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 for behavioral disclosure. It states what the tool does but lacks critical details: it doesn't specify if this is a read-only operation (implied by 'Get' but not explicit), whether it requires specific permissions, how results are formatted (e.g., list structure), or if there are rate limits. For a 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, efficient sentence that front-loads the core purpose ('Get all links for a specific note') and adds clarifying detail ('incoming, outgoing internal, and external') without redundancy. Every word earns its place, making it easy to parse quickly, with no wasted verbiage or structural issues.
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 (retrieving multiple link types), lack of annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose but misses behavioral context (e.g., safety, permissions) and output details. With 100% schema coverage for the single parameter, it's not severely lacking, but more completeness would help compensate for missing structured data.
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 100% description coverage, with the single parameter 'identifier' documented as 'Note identifier (type/filename format)'. The description adds no additional parameter semantics beyond what the schema provides—it doesn't clarify the identifier format further or provide examples. Baseline 3 is appropriate since the schema does the heavy lifting, but no extra value is added.
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 ('Get all links') and target resource ('for a specific note'), specifying the types of links retrieved (incoming, outgoing internal, and external). It distinguishes from siblings like 'get_backlinks' (which likely only retrieves incoming links) and 'find_broken_links' (which focuses on problematic links). However, it doesn't explicitly contrast with 'search_by_links' or 'migrate_links', leaving some 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. It doesn't mention when to prefer 'get_backlinks' for only incoming links, 'search_by_links' for link-based searches, or 'find_broken_links' for identifying issues. There's also no context about prerequisites (e.g., note must exist) or exclusions, leaving usage decisions to inference from tool names 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 the full burden of behavioral disclosure. It states it 'gets' information, implying a read-only operation, but doesn't specify permissions required, rate limits, error conditions, or what 'comprehensive information' entails beyond 'instructions and description'. For a tool with no annotation coverage, this leaves significant behavioral gaps unaddressed.
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 action ('Get comprehensive information') and specifies key details ('including instructions and description'). There is no wasted verbiage or redundancy, making it appropriately sized and 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 (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output specifics. With no output schema, it should ideally hint at return values, but it doesn't. It meets a bare minimum but has clear gaps 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?
The description adds no parameter semantics beyond what the input schema provides. The schema has 100% description coverage, clearly documenting both parameters ('type_name' and optional 'vault_id'). The description doesn't elaborate on parameter usage, constraints, or examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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 the resource 'comprehensive information about a note type', specifying it includes 'instructions and description'. It distinguishes from siblings like 'get_note' (which retrieves note content) and 'list_note_types' (which lists types without details), though it doesn't explicitly name these alternatives. The purpose is specific but could be more precise 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 scenarios like needing metadata versus content, or compare to siblings such as 'get_note_info' (which might provide different note details) or 'list_note_types' (which lists types without comprehensive info). Usage is implied only by the tool name, with no explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists vaults with status and information, which implies a read-only operation, but doesn't disclose behavioral traits such as permissions required, rate limits, pagination, or format of returned data. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it 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 front-loads the key action ('List all configured vaults') and adds necessary detail ('with their status and information'). There is no wasted verbiage, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It specifies what the tool does but lacks details on return values, error handling, or operational context. For a simple list tool, it meets basic needs but could be more complete by describing the output structure or usage scenarios.
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 there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. Baseline for 0 parameters is 4, as it avoids unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all configured vaults'), specifying what information is included ('status and information'). It distinguishes from sibling tools like 'get_current_vault' or 'create_vault' by indicating it returns all vaults rather than a single one or performing a mutation. However, it doesn't explicitly differentiate from potential similar tools like 'get_vaults' if they existed.
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 configured vaults), exclusions, or comparisons to siblings like 'get_current_vault' for active vault or 'remove_vault' for deletion. Usage is implied by the action but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, it doesn't specify permissions needed, whether the operation is idempotent, what happens if the vault already exists, or error conditions. It mentions adding to a registry but doesn't explain what that entails or the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and outcome, making it easy to parse quickly. Every part of the sentence contributes 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?
For a creation tool with no annotations and no output schema, the description is minimally adequate but lacks completeness. It doesn't address behavioral aspects like error handling, side effects, or what 'add it to the vault registry' means in practice. Given the complexity of creating a vault with 6 parameters, more context would be helpful.
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 100%, so the schema fully documents all 6 parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't clarify relationships between parameters like 'id' and 'path'). Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 ('Create a new vault') and the outcome ('add it to the vault registry'), distinguishing it from sibling tools like 'list_vaults', 'remove_vault', or 'update_vault'. It uses precise verbs and identifies the resource being created.
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., whether a vault registry must exist), when not to use it, or how it relates to sibling tools like 'switch_vault' or 'remove_vault'. Usage is implied 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that removal is from the registry and does not delete files, which is useful behavioral context. However, it lacks details on permissions needed, whether the action is reversible, error conditions, or what happens to associated notes/vault 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, efficient sentence that front-loads the core action and clarifies a key behavioral point (no file deletion). There is no wasted text, making it appropriately concise for a simple 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 no annotations and no output schema, the description is minimally complete for a destructive operation—it states the action and a critical constraint (files not deleted). However, it lacks details on side effects, success indicators, or error handling, which are important 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 100%, so the schema already documents the 'id' parameter fully. The description adds no additional meaning about the parameter, such as format examples or where to find the ID, but doesn't need to compensate for 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 action ('Remove') and resource ('a vault from the registry'), distinguishing it from siblings like 'delete_note' or 'delete_note_type' which handle different resources. However, it doesn't specify what 'registry' refers to or differentiate from 'bulk_delete_notes' 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 like 'delete_vault' (if existed) or 'bulk_delete_notes', nor prerequisites such as needing the vault to be empty or inactive. The description implies it's for removal from a registry, but doesn't clarify context 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 mentions that empty queries return all notes sorted by last updated, which is useful context. However, it doesn't cover critical aspects like pagination behavior (beyond the 'limit' parameter), error handling, rate limits, or authentication needs, leaving significant gaps for a search 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 extremely concise with two sentences that directly convey key information: the tool's purpose and a behavioral note about empty queries. Every word earns its place, and it's front-loaded with the core functionality.
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 (6 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and one behavioral trait, but lacks details on output format, error cases, or performance characteristics. Without annotations or an output schema, more context would be helpful for effective use.
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 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value beyond the schema: it implies that 'query' and 'type_filter' are the primary search criteria, but doesn't provide additional syntax, format details, or examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search notes by content and/or type.' It specifies the verb ('search') and resource ('notes'), and mentions the search criteria. However, it doesn't explicitly differentiate from siblings like 'search_notes_advanced' or 'search_notes_sql', which would be needed for 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance: 'Empty queries return all notes sorted by last updated.' This suggests when to use it for unfiltered retrieval. However, it lacks explicit guidance on when to choose this tool over alternatives like 'search_notes_advanced' or 'search_notes_sql', and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 mentions what data is returned (purposes and agent instructions) but doesn't disclose behavioral aspects like whether this is a read-only operation, if it requires specific permissions, how results are formatted, or if there are rate limits. For a tool with no 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?
The description is a single, efficient sentence that directly states the tool's function and output. It's front-loaded with the core purpose and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose but lacks details on behavior, return format, or error handling. For a simple list tool with one optional parameter, it's minimally adequate but could be more complete by explaining the structure of the returned note types.
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 100%, so the schema already documents the single optional parameter 'vault_id' with its description. The description adds no additional parameter information beyond what the schema provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all available note types') and specifies what information is returned ('with their purposes and agent instructions'). It distinguishes this tool from siblings like 'get_note_type_info' (which gets info about a specific type) and 'list_notes_by_type' (which lists notes of a type).
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 when needing to see all note types with their metadata, but doesn't explicitly state when to use this vs alternatives like 'get_note_type_info' for a specific type. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, its performance characteristics, error handling, or output format. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any redundant information. It's appropriately sized and front-loaded with 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 apparent simplicity (no parameters, likely a read operation) but lack of annotations and output schema, the description is minimally adequate. It explains what the tool does but doesn't provide enough context about behavior or results for confident use. The absence of output schema means the description should ideally hint at return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema). The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose. This meets the baseline expectation for parameterless tools.
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 ('all broken wikilinks'), with explicit qualification ('links to non-existent notes'). It distinguishes from siblings like 'get_note_links' (which presumably gets all links) and 'search_by_links' (which likely searches by link patterns).
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 when needing to identify broken wikilinks, but provides no explicit guidance on when to use this versus alternatives like 'get_note_links' or 'search_by_links', nor any prerequisites or exclusions. The context is clear but lacks comparative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a mutation operation (rename), it preserves filename/ID to maintain links, and it automatically updates wikilinks in other notes. However, it doesn't mention potential side effects like permission requirements, error conditions, or whether the operation is reversible.
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 perfectly concise with just two sentences that each earn their place. The first sentence states the core functionality, and the second adds important behavioral context about link preservation and automatic updates. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well by explaining the core behavior and side effects. However, it doesn't describe what the tool returns or potential error cases. Given the complexity of a rename operation with link updates, some additional context about return values would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds some context about what 'identifier' represents and implies the purpose of 'new_title', but doesn't provide additional semantic meaning beyond what's already documented in the schema descriptions for each parameter.
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 ('rename a note by updating its title field') and distinguishes it from siblings like 'update_note' by specifying it only changes the display name while preserving filename/ID. It also mentions the automatic wikilink update feature, which is unique among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (to rename a note's display title while preserving links), but doesn't explicitly state when NOT to use it or mention specific alternatives like 'update_note' for other modifications. It implies usage through the specific functionality described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a read-only operation ('Only SELECT queries allowed'), operates on a notes database, and offers maximum flexibility. However, it doesn't mention potential risks like SQL injection, performance impacts, or error handling, which could be useful context for an AI 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 extremely concise and front-loaded, consisting of just two sentences that efficiently convey the tool's purpose and key constraint. Every word earns its place, with no wasted text or redundancy, making it easy for an AI 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 complexity (SQL-based search with 6 parameters) and no annotations or output schema, the description is somewhat complete but has gaps. It covers the purpose and constraint well, but lacks details on return format, error cases, or performance considerations. For a flexible SQL tool, more context on results structure or limitations would be helpful.
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 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain SQL syntax or table relationships further). This meets the baseline of 3 when the schema does the heavy lifting, but doesn't compensate with extra insights.
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 tool's purpose with specific verb ('Direct SQL search') and resource ('against notes database'), distinguishing it from sibling tools like 'search_notes' or 'search_notes_advanced' by emphasizing maximum flexibility through SQL. It explicitly mentions 'Only SELECT queries allowed', which further clarifies its scope compared to other note manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines by stating 'Only SELECT queries allowed', which tells the agent when to use this tool (for flexible SQL queries) and when not to (for non-SELECT operations). It implies alternatives like 'search_notes' or 'search_notes_advanced' for simpler searches, as this tool is for maximum flexibility with SQL.
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/disnet/flint-note-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server