Obsidian MCP Server

by Vasallo94

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is some overlap that could cause confusion. For example, 'agregar_a_nota' and 'agregar_en_seccion' both add content to notes with subtle differences, and 'analizar_enlaces' vs 'obtener_backlinks' vs 'obtener_grafo_local' all deal with note links but in different ways. The descriptions help clarify, but an agent might misselect without careful reading.
Naming Consistency2/5
Naming is inconsistent with mixed conventions. Some tools use Spanish verbs like 'agregar' or 'analizar', others use English verbs like 'get' or 'list', and there are variations in style such as 'buscar_en_notas' vs 'buscar_notas_por_fecha'. This lack of a predictable pattern increases cognitive load for agents.
Tool Count2/5
With 35 tools, the count is excessive for an Obsidian vault management server. Many tools could be consolidated or removed without losing functionality, such as having separate tools for 'analizar_enlaces', 'analizar_etiquetas', and 'estadisticas_vault' instead of a unified analysis tool. This bloats the interface and complicates agent decision-making.
Completeness5/5
The tool set provides comprehensive coverage for managing an Obsidian vault, including CRUD operations for notes (crear_nota, leer_nota, editar_nota, eliminar_nota), advanced features like linking analysis and skill management, and utilities for searching, tagging, and synchronization. No obvious gaps exist for the domain.
Average 3.7/5 across 35 of 35 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches for notes modified in a date range, implying a read-only operation, but doesn't specify whether it returns all matching notes or paginated results, what format the output takes, or if there are any rate limits or authentication requirements. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args:' section for parameters. There's no wasted text, and the information is organized for quick parsing. However, it could be slightly more polished (e.g., using consistent formatting).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (date-range search), no annotations, and an output schema present (which reduces the need to describe return values), the description is minimally complete. It covers the purpose and parameters but lacks behavioral details like pagination or error handling. With output schema handling return values, the description is adequate but could be more informative about operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description compensates by explaining both parameters: 'fecha_desde' as the start date (YYYY-MM-DD) and 'fecha_hasta' as the optional end date (defaulting to today). This adds meaningful semantics beyond the bare schema, but doesn't cover edge cases like invalid date formats or timezone handling. With 2 parameters and low schema coverage, this is adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Busca notas modificadas en un rango de fechas' (Search for notes modified in a date range). It specifies the verb (buscar/search) and resource (notas/notes) with a clear scope (modified in a date range). However, it doesn't explicitly differentiate from sibling tools like 'buscar_en_notas' (search in notes) or 'listar_notas' (list notes), which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'buscar_en_notas' (which might search by content) or 'listar_notas' (which might list all notes without date filtering), leaving the agent to infer usage based on the name and parameters alone. No explicit when/when-not or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions synchronization but does not detail whether this is a read-only or mutating operation, what permissions are required, potential side effects (e.g., data modification), or error handling. The description lacks critical behavioral traits, leaving gaps in understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with a clear main sentence followed by a parameter explanation. There is no wasted text, and the structure efficiently conveys the tool's purpose and parameter usage in a few lines, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (which should cover return values), the description is moderately complete. It explains the parameter's semantics but lacks behavioral details and usage guidelines. For a synchronization tool with no annotations, more context on how it interacts with the vault and registry would improve completeness, but the presence of an output schema mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'actualizar,' explaining that if True, it attempts to update the statistics table in the registry file. This clarifies the parameter's purpose beyond the schema's basic boolean type and default value, compensating for the 0% schema description coverage by providing actionable semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'synchronizes tag usage in the vault with the official registry,' which provides a general purpose but lacks specificity about what synchronization entails (e.g., reconciling differences, updating metadata). It distinguishes from siblings by focusing on tag synchronization, but the verb 'synchronizes' is somewhat vague without detailing the action's scope or outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description mentions synchronization but does not specify triggers, prerequisites, or compare it to sibling tools like 'obtener_lista_etiquetas' or 'obtener_tags_canonicas.' Usage is implied for tag management tasks, but without clear 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 states the tool modifies a file and returns a message, but doesn't describe what happens if the file doesn't exist, whether changes are append-only or overwrite, permission requirements, or error handling. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the purpose in the first sentence. The Args and Returns sections are structured clearly, though the Spanish formatting ('Args:', 'Returns:') is slightly informal. Every sentence adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, mutation operation) and no annotations, the description is minimally adequate. It covers the purpose and parameters well, and an output schema exists, so return values needn't be explained. However, it lacks behavioral context like error conditions or side effects, which is a gap for a tool that modifies files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds clear meaning for all three parameters: 'nombre_archivo' (file name to modify), 'contenido' (content to add), and 'al_final' (whether to add at the end or beginning). This fully documents parameter purposes beyond the bare schema, though it lacks format details like file extensions or content constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Agrega contenido a una nota existente' (Adds content to an existing note). It specifies the verb 'agregar' (add) and the resource 'nota existente' (existing note), which distinguishes it from sibling tools like 'crear_nota' (create note) or 'editar_nota' (edit note). However, it doesn't explicitly differentiate from 'agregar_en_seccion' (add to section), 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'editar_nota' (edit note) or 'agregar_en_seccion' (add to section), nor does it specify prerequisites like needing an existing note. Usage is implied by the purpose but lacks explicit 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 full burden. It states what the tool does but lacks behavioral details: it doesn't specify if this is a read-only operation, performance characteristics (e.g., slow for large vaults), or side effects (e.g., caching). The return format is mentioned but without elaboration on structure or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded: the first sentence defines the purpose, and the second clarifies the return value. There's no wasted text, though it could be slightly more structured (e.g., separating purpose and returns more clearly). It efficiently conveys essential information in two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is adequate but minimal. It explains the purpose and return type but lacks context like when this is useful or behavioral traits. For a simple query tool, this is passable but leaves gaps in usage guidance and transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description correctly omits parameter details, focusing on the tool's function. A baseline of 4 is appropriate as it avoids redundancy while being complete for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Encuentra notas huérfanas' (finds orphaned notes) with the specific criterion 'sin enlaces entrantes ni salientes' (without incoming or outgoing links). It distinguishes from siblings like 'listar_notas' or 'obtener_backlinks' by focusing on disconnected notes. However, it doesn't explicitly differentiate from all possible alternatives, keeping it at 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or compare with siblings like 'analizar_enlaces' or 'obtener_grafo_local' that might offer related functionality. The agent must infer usage from the purpose 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 mentions listing notes and includes parameter descriptions, but does not cover important behavioral aspects such as whether this is a read-only operation, how results are formatted (e.g., list of file paths or metadata), pagination, error handling, or performance considerations. The description adds minimal context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the main purpose stated first followed by parameter explanations. Both sentences earn their place by providing essential information without redundancy. However, the structure could be slightly improved by integrating parameter details more seamlessly or adding brief usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no annotations, but has an output schema), the description is moderately complete. It covers the purpose and parameters adequately, but lacks behavioral details (e.g., output format, error cases) and usage guidelines. The presence of an output schema reduces the need to describe return values, but overall completeness is limited by missing context on when and how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for both parameters: 'carpeta' is explained as a specific folder to explore (empty = vault root), and 'incluir_subcarpetas' indicates whether to include subfolders in the search. With 0% schema description coverage, this compensates well by clarifying parameter purposes and default behaviors, though it lacks format details (e.g., folder path syntax).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista todas las notas (.md) en el vault o en una carpeta específica' (Lists all notes (.md) in the vault or in a specific folder). It specifies the verb ('Lista'), resource ('notas'), and scope ('vault o en una carpeta específica'), but does not explicitly differentiate it from sibling tools like 'buscar_en_notas' or 'obtener_notas_por_tag', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools or contexts where other tools might be more appropriate, such as using 'buscar_en_notas' for keyword searches or 'obtener_notas_por_tag' for tag-based filtering. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 returns a list of template names, which is basic output info, but lacks details on permissions, rate limits, error conditions, or whether it's read-only/destructive. For a tool with zero annotation coverage, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and resource. The second sentence clarifies the return value efficiently. No wasted words, though it could be slightly more structured (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters, 100% schema coverage, and an output schema (implied by 'Returns'), the description is adequate but minimal. It covers what the tool does and the return format, but for a tool with no annotations, it lacks behavioral context like safety or constraints, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%. The description doesn't need to explain parameters, and it correctly doesn't mention any. Baseline for 0 parameters is 4, as it avoids unnecessary parameter discussion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista') and resource ('plantillas disponibles'), specifying they are in the 'carpeta ZZ_Plantillas'. It distinguishes from siblings like 'listar_notas' by focusing on templates, but doesn't explicitly contrast with other listing tools. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or compare to siblings like 'obtener_lista_etiquetas' or 'listar_notas'. Usage is implied only by the folder location, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns a 'Visualización del grafo local de la nota' (Visualization of the note's local graph), which hints at a visual output rather than raw data. However, it doesn't disclose critical behavioral traits: whether this is a read-only operation, if it requires specific permissions, performance implications (e.g., for large graphs), 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured 'Args' and 'Returns' sections. There's no wasted text. However, the Spanish language might add slight complexity for non-Spanish agents, but it's still efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is partially complete. It explains the parameters and return value ('Visualización del grafo local'), but lacks behavioral context (e.g., safety, performance). The output schema existence means the description doesn't need to detail return values, but it should still cover usage and behavioral aspects more thoroughly for a tool that likely involves graph traversal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains both parameters: 'nombre_nota' (central note name) and 'profundidad' (depth levels, with 1 meaning direct connections only). Since schema description coverage is 0%, this compensates well by providing clear semantics. It doesn't cover all possible nuances (e.g., format of 'nombre_nota', range for 'profundidad'), but it adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtiene el grafo local de una nota: enlaces salientes y entrantes' (Gets the local graph of a note: outgoing and incoming links). It specifies the verb ('obtiene') and resource ('grafo local de una nota'), and distinguishes it from siblings like 'obtener_backlinks' by focusing on both directions and graph visualization. However, it doesn't explicitly contrast with 'analizar_enlaces' or other graph-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to siblings like 'obtener_backlinks' (which might get backlinks only), 'analizar_enlaces' (which might analyze links differently), or 'leer_nota' (which reads note content). There's no context about prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves content from a SKILL.md file, implying a read-only operation, but doesn't specify whether this requires permissions, what happens if the skill doesn't exist, or any rate limits. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and another explaining the parameter with an example. It's front-loaded with the main function, and the example ('ej: 'escritor'') adds clarity without unnecessary detail. There's no wasted text, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 1 parameter with good semantic coverage in the description, and no annotations, the description is minimally adequate. However, for a tool that likely interacts with a file system or database (implied by 'SKILL.md'), it lacks details on error handling, authentication, or behavioral traits, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the single parameter 'nombre', explaining it as 'El nombre de la carpeta de la skill (ej: 'escritor')' which clarifies it's the folder name of the skill, not the file name or another identifier. With 0% schema description coverage, this compensates well by providing essential context beyond the bare schema type (string).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtiene el contenido de una Skill específica (SKILL.md)' which translates to 'Gets the content of a specific Skill (SKILL.md)'. This specifies the verb ('obtiene' - gets) and resource ('Skill específica' - specific Skill), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'leer_nota' (read note) or 'leer_contexto_vault' (read vault context), which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools such as 'leer_nota' or 'generar_skill'. The agent must infer usage based solely on the tool name and description without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it returns categorized tags. It doesn't disclose whether this is a read-only operation, whether it requires specific permissions, how it handles errors, or any performance characteristics. The description is minimal and lacks behavioral context needed for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address what the tool does and what it returns. There's no wasted verbiage, and the information is front-loaded. However, the second sentence about returns could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, but has an output schema, the description is minimally adequate. It explains what the tool retrieves and mentions the return format, but for a tool with no annotation coverage, it should provide more behavioral context about how it operates, especially since there's a sibling tool 'obtener_lista_etiquetas' that seems similar.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since there are none, and the schema fully documents the empty input structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtiene' - gets/retrieves) and resource ('lista de tags oficiales/canónicas'), specifying they come from a specific file. It distinguishes from sibling 'obtener_lista_etiquetas' by specifying these are 'official/canonical' tags from a registry file rather than all tags in the 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'obtener_lista_etiquetas' or 'obtener_notas_por_tag'. It doesn't mention prerequisites, timing considerations, or when this tool would be preferred over other tag-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions scanning usage patterns and returning suggestions, but does not specify whether this is a read-only operation, potential performance impacts, rate limits, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using two sentences that efficiently convey the tool's purpose and process. It avoids unnecessary details and is front-loaded with the main action. However, it could be slightly improved by integrating usage guidelines without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. However, with no annotations and a focus on analysis and suggestions, it lacks details on behavioral traits like data handling or limitations. The description is adequate for a simple tool but misses opportunities to clarify context, such as how suggestions are generated or any dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description does not add parameter details, which is appropriate here. Baseline is 4 for zero parameters, as the schema fully covers the inputs without requiring additional explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing a vault to suggest personalized skills based on usage patterns. It specifies the verb 'analiza' (analyzes) and resource 'vault' with the outcome 'sugiere skills personalizadas' (suggests personalized skills). However, it does not explicitly differentiate from sibling tools like 'generar_skill' or 'sincronizar_skills', which might have overlapping functions, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks explicit instructions on when or when not to invoke it, prerequisites, or comparisons to sibling tools such as 'generar_skill' or 'estadisticas_vault'. Usage is implied through the action described but without clear contextual boundaries.
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. 'Analiza' implies a read-only analysis operation, but it doesn't disclose behavioral traits such as whether it requires specific permissions, what format the analysis output takes (e.g., report, list, graph), performance characteristics, or error conditions. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized for a no-parameter tool and front-loads the core action ('Analiza'). Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists (which should document return values), the description is minimally adequate. However, it lacks context about what 'analiza' means in practice (e.g., depth of analysis, output format), and with no annotations, it doesn't cover behavioral aspects. For a simple analysis tool, it meets basic needs but leaves room for improvement in clarifying the analysis scope and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics beyond stating the analysis scope ('en el vault'), which it does. A baseline of 4 is appropriate as the schema fully covers the parameter situation (none), and the description doesn't introduce confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analiza los enlaces internos en el vault' clearly states the action (analiza/analyzes) and target (enlaces internos/internal links in the vault). It distinguishes from siblings like 'obtener_backlinks' (which might get backlinks) or 'encontrar_notas_huerfanas' (which finds orphaned notes) by focusing on analysis of internal links. However, it doesn't specify what 'analiza' entails (e.g., statistical analysis, visualization, or listing), making it slightly less specific than a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for analysis, or differentiate from similar tools like 'obtener_backlinks' or 'obtener_grafo_local' (which might handle link graphs). Without any usage context, the agent must infer 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool analyzes tag usage, implying a read-only operation, but does not specify what 'analyzes' entails—e.g., whether it returns statistics, patterns, or summaries, or if it has any side effects like caching. For a tool with zero annotation coverage, this is insufficient to inform the agent about its behavior beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Analiza el uso de etiquetas en el vault.' It is front-loaded with the core purpose, has no redundant words, and efficiently conveys the essential information without any fluff. This is an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, an output schema exists (which should cover return values), and no annotations are provided, the description is minimally adequate. It states what the tool does but lacks details on behavior, output format, or usage context. For a simple analysis tool, this might suffice, but it leaves gaps in understanding how the analysis is performed or what results to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). With no parameters, the description does not need to add parameter semantics. It appropriately focuses on the tool's purpose without unnecessary details, meeting the baseline for parameter-less tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analiza el uso de etiquetas en el vault' clearly states the tool's purpose: analyzing tag usage in the vault. It specifies the verb 'analiza' (analyzes) and the resource 'etiquetas en el vault' (tags in the vault), making it unambiguous. However, it does not explicitly differentiate from sibling tools like 'obtener_lista_etiquetas' or 'obtener_notas_por_tag', which might offer related functionality, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it refer to sibling tools like 'obtener_lista_etiquetas' for listing tags or 'obtener_notas_por_tag' for fetching notes by tag. This lack of usage instructions leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool generates statistics but doesn't clarify what types of statistics, whether it's read-only or has side effects, performance implications, or output format. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundant information. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, an output schema exists, and no annotations are provided, the description is minimally adequate. However, it lacks details about what 'estadísticas completas' entails, potential side effects, or how it differs from sibling tools, leaving room for improvement in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately focuses on the tool's purpose without unnecessary parameter details, earning a high baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Genera') and resource ('estadísticas completas del vault de Obsidian'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'resumen_actividad_reciente' or 'leer_contexto_vault', which might provide related statistical or overview functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based solely on the purpose statement without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions listing skills but doesn't describe traits like whether it's read-only, requires permissions, returns structured data, or has side effects. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for its simple function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks behavioral context and usage guidelines, which are needed for full completeness, especially without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add param details, but this is acceptable given the lack of parameters, warranting a baseline score above minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista') and the resource ('skills (agentes) disponibles en el vault'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'listar_notas' or 'obtener_lista_etiquetas', which list other resources, so it lacks sibling distinction 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'listar_notas' or 'obtener_lista_etiquetas'. It merely states what it does without context or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it searches for notes by tag, but does not disclose behavioral traits such as whether it returns partial matches, case sensitivity, performance characteristics, or error handling. The description adds minimal context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured 'Args' and 'Returns' sections. There is no wasted text, though the structure could be slightly more integrated (e.g., combining into a single paragraph).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter), no annotations, and the presence of an output schema (which handles return value documentation), the description is reasonably complete. It covers the purpose, parameter meaning, and return type, though it lacks behavioral details like search scope or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explaining the 'tag' parameter: 'Etiqueta a buscar (con o sin #)' (Tag to search for, with or without #). This adds meaningful semantics beyond the schema's type definition, clarifying format flexibility. With only one parameter, this is sufficient for a high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Busca todas las notas que contienen una etiqueta específica' (Search all notes containing a specific tag). It specifies the verb (busca/search) and resource (notas/notes), but does not explicitly differentiate it from sibling tools like 'buscar_en_notas' or 'buscar_notas_por_fecha', which is why it scores 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'buscar_en_notas' (general search) or 'buscar_notas_por_fecha' (date-based search), nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's action (generating a skill and creating SKILL.md with specific sections) and implies a write operation, but lacks details on permissions, error handling, or side effects. It adds some context by specifying the file structure, but doesn't cover behavioral traits like whether the operation is idempotent or if it overwrites existing files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, details the output (SKILL.md creation), and lists parameters with explanations. Each sentence adds value, with no redundant information. However, it could be slightly more front-loaded by integrating the parameter details more seamlessly, but overall it's efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a write operation with 5 parameters), no annotations, and an output schema present, the description is moderately complete. It explains the tool's action and parameters well, but lacks behavioral context like permissions or error handling. The output schema likely covers return values, so the description doesn't need to explain those, but it should address more usage and safety aspects for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 5 parameters in the 'Args' section, including examples (e.g., 'profesor-fisica' for 'nombre') and explanations (e.g., 'Descripción breve de lo que hace la skill' for 'descripcion'). This adds significant value beyond the bare schema, though it doesn't cover validation rules or constraints beyond the examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Genera una nueva skill con estructura consistente' (Generates a new skill with consistent structure). It specifies the verb 'genera' and resource 'skill', and mentions the automatic creation of SKILL.md with specific components. However, it doesn't explicitly differentiate from sibling tools like 'sincronizar_skills' or 'sugerir_skills_para_vault', which are related to skills but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as whether the skill already exists or if specific permissions are needed, nor does it refer to sibling tools like 'sincronizar_skills' for managing existing skills. Usage is implied only through the action of creating a new skill, 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 the full burden of behavioral disclosure. While it states this is a read operation ('Lee'), it doesn't mention potential errors (e.g., file not found, permission issues), whether it returns metadata alongside content, or any performance characteristics. For a read tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with zero wasted words. The purpose is stated in one clear sentence, followed by a parameter explanation with a helpful example. Every element serves a purpose, and the structure separates the main description from parameter details cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema (which handles return value documentation), the description is reasonably complete. It explains what the tool does and provides parameter format guidance. The main gaps are lack of error behavior disclosure and no differentiation from sibling tools, but given the simplicity of the operation and presence of an output schema, it's mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by providing a clear example of the single parameter's format: 'Nombre del archivo (ej: "Diario/2024-01-01.md")'. This gives concrete guidance on the expected path structure, which is valuable beyond the schema's basic string type. However, it doesn't explain constraints like allowed file extensions or path validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lee' - reads) and resource ('contenido completo de una nota especifica' - full content of a specific note), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'listar_notas' or 'obtener_backlinks', but the specificity of reading full content of a single note is clear enough to distinguish it from listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'buscar_en_notas', 'buscar_notas_por_fecha', 'obtener_notas_por_tag', and 'leer_contexto_vault', there's no indication of when this specific read operation is preferred over other retrieval methods. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 generates a summary, implying a read-only operation, but doesn't specify whether it requires permissions, how it handles data (e.g., aggregation methods), or any rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief parameter explanation. There's no wasted text, and every sentence adds value. The structure is clear and efficient, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (one parameter, no annotations, but with an output schema), the description is reasonably complete. It covers the purpose and parameter semantics adequately. Since an output schema exists, the description doesn't need to explain return values. However, it lacks behavioral details (e.g., how the summary is generated), which slightly reduces completeness for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'dias' by explaining it as 'Número de días hacia atrás para analizar (por defecto 7)' (Number of days backward to analyze, default 7). Since schema description coverage is 0% (the schema only defines type and default without description), this compensates well by clarifying the parameter's purpose and default value. With only one parameter, this is sufficient for a high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Genera un resumen de la actividad reciente en el vault' (Generates a summary of recent activity in the vault). It specifies the verb 'genera' (generates) and the resource 'actividad reciente en el vault' (recent activity in the vault), which is distinct from sibling tools like 'estadisticas_vault' or 'listar_notas'. However, it doesn't explicitly differentiate from all siblings (e.g., 'leer_contexto_vault' might overlap in scope), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools like 'estadisticas_vault' or 'buscar_notas_por_fecha', which might serve similar purposes. The agent must infer usage based on the name and description alone, with no 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions moving/renaming and folder creation, but lacks details on permissions, error handling (e.g., what happens if 'origen' doesn't exist), side effects, or rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The Args and Returns sections are structured but slightly verbose; every sentence earns its place by explaining parameters and outcomes clearly, with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, mutation operation) and no annotations, the description is fairly complete: it covers purpose, parameters with examples, and return values. However, it lacks behavioral details like error cases or side effects, and while an output schema exists, more context on usage could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all three parameters: 'origen' (current relative path with example), 'destino' (new relative path with example), and 'crear_carpetas' (create folders if missing with default). It adds essential meaning beyond the bare schema, clarifying usage and examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Mueve o renombra') and resource ('una nota dentro del vault'), distinguishing it from siblings like 'crear_nota' (create), 'editar_nota' (edit), and 'eliminar_nota' (delete). It precisely defines the tool's function as moving or renaming notes within a 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where moving is preferred over renaming with 'editar_nota', or how it relates to sibling tools like 'sugerir_ubicacion' (suggest location) or 'listar_notas' (list notes). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('invalida y refresca') which implies mutation, but doesn't describe side effects, permissions needed, or what 'refrescar' entails operationally. This leaves 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates both purpose and usage guidelines without any wasted words. It's appropriately sized and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations but has an output schema, the description provides basic purpose and usage but lacks details about behavioral traits, side effects, or what the refresh operation actually does. The output schema may help with return values, but the description should do more for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to add parameter information, and it appropriately focuses on usage context instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('invalida y refresca') and resource ('el caché de skills'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'sincronizar_skills' or 'generar_skill', 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('tras editar SKILL.md'), giving practical guidance. It doesn't explicitly state when not to use it or name alternatives, which keeps it from a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it validates skills for specific issues and can apply corrections based on the 'actualizar' parameter. However, it doesn't mention side effects (e.g., whether changes are reversible), performance aspects (e.g., time/rate limits), or error handling, which are gaps for a tool that modifies content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized: it starts with the core purpose, lists specific problems detected, and explains the key parameter. Each sentence adds value without redundancy. It could be slightly more concise by integrating the parameter explanation into the main text, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (validation and optional correction), no annotations, and an output schema (which handles return values), the description is reasonably complete. It covers the purpose, validation targets, and parameter behavior. However, it lacks details on scope (e.g., which skills are validated) and error cases, which could enhance completeness for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 parameter with 0% description coverage, so the description must compensate. It adds clear semantics: 'actualizar' controls whether corrections are applied (True) or only reported (False). This goes beyond the schema's boolean type, providing crucial context for the agent's decision-making. Since there are no other parameters, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Sincroniza y valida las skills existentes' (synchronizes and validates existing skills). It specifies the verb (synchronize/validate) and resource (existing skills), making it distinct from siblings like 'generar_skill' (create new) or 'refrescar_cache_skills' (refresh cache). However, it doesn't explicitly differentiate from all siblings, such as 'sincronizar_registro_tags', which might have overlapping validation aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the listed problem detections (e.g., missing references, incorrect frontmatter), suggesting it's for maintaining skill integrity. However, it lacks explicit guidance on when to use this tool versus alternatives like 'refrescar_cache_skills' or 'generar_skill', and doesn't specify prerequisites or exclusions, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what happens when the language parameter is omitted (searches for manual subtitles in original language, fails on auto-generated ones) and mentions error messages in returns. However, it doesn't cover important behavioral aspects like rate limits, authentication requirements, or what specific error conditions might occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and front-loaded with the core purpose. Every sentence adds value, though the Spanish language might require translation for some agents. The structure is efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return value documentation) and the description provides good parameter semantics despite 0% schema coverage, the description is reasonably complete. It covers the core functionality, parameter behaviors, and return expectations adequately for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains that the 'url' parameter accepts either a YouTube URL or video ID, and clarifies the 'language' parameter with examples ('es', 'en') and behavior when omitted. This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Obtiene' - gets/obtains) and resource ('transcripción de un video de YouTube'), making it immediately understandable. It distinguishes itself from all sibling tools, which appear to be note/vault management tools, by focusing exclusively on YouTube transcripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it's clearly distinct from the sibling tools (which are all note/vault management related), there's no mention of potential alternative tools for similar functions or specific scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects like whether it's read-only (implied but not stated), performance characteristics, error conditions, or what happens with invalid note names. The description is functional but lacks operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise - a clear purpose statement followed by Args and Returns sections. Every sentence earns its place, with no redundant information. The Spanish language is used consistently and efficiently throughout.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter query tool with an output schema (which handles return value documentation), the description is reasonably complete. It explains what the tool does, what the parameter means, and what it returns. The main gap is lack of behavioral context about performance, errors, or limitations, but given the tool's simplicity and the presence of an output schema, it's mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear semantic meaning for the single parameter 'nombre_nota' - it's the name of the note (with or without .md extension). With 0% schema description coverage, this description fully compensates by explaining what the parameter represents and its format flexibility, though it doesn't specify constraints like maximum length or character restrictions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('obtiene' - gets) and resource ('todas las notas que enlazan a la nota especificada' - all notes linking to the specified note). It distinguishes itself from siblings like 'leer_nota' (read note) or 'analizar_enlaces' (analyze links) by focusing specifically on backlinks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context - when you need to find notes that link to a specific note. However, it doesn't explicitly state when to use this versus alternatives like 'analizar_enlaces' or 'obtener_grafo_local', nor does it provide exclusion criteria or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions extracting a random concept but does not describe how randomness is implemented, what format the output takes, whether it requires specific permissions, or any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the first sentence stating the core purpose, followed by usage context and parameter details. Every sentence earns its place without redundancy, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and low schema coverage, the description is moderately complete. It covers purpose, usage, and parameter semantics but lacks behavioral details like output format hints or error handling, leaving room for improvement in contextual richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the single parameter 'carpeta', explaining it as a specific folder to search in, with an empty value meaning the entire vault. With schema description coverage at 0%, this compensates well by clarifying the parameter's purpose and default behavior, though it could specify folder format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Extrae un concepto aleatorio') and resource ('del vault'), distinguishing it from siblings like 'leer_nota' or 'listar_notas' by emphasizing randomness and surprise. It explicitly mentions use as a 'flashcard sorpresa' for reinforcement or discovery, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Util para reforzar conocimiento o descubrir notas olvidadas'), but does not explicitly state when not to use it or name alternatives among siblings. It implies usage for random concept extraction versus structured searches, though lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a formatted string list, which is useful behavioral context. However, it doesn't mention potential limitations like rate limits, permissions needed, or whether the list is cached/real-time, leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a usage tip and return format, all in three concise sentences. Every sentence adds value without redundancy, making it efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is reasonably complete. It explains what the tool does, when to use it, and the return format. With an output schema, it doesn't need to detail return values further, though more behavioral context could enhance it for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information beyond what the schema already covers perfectly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtiene' (gets) and resource 'lista de las etiquetas existentes en el vault' (list of existing tags in the vault), making the purpose specific and understandable. It doesn't explicitly differentiate from sibling tools like 'obtener_tags_canonicas' or 'analizar_etiquetas', but the focus on a 'lista simple' (simple list) provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Útil para ver qué etiquetas ya existen antes de crear nuevas' (Useful to see what tags already exist before creating new ones). This gives practical guidance, though it doesn't explicitly state when not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it modifies notes (implied by 'añade'), describes the insertion algorithm (searching for headings and placing content before next heading of same or higher level), and mentions conditional section creation. However, it doesn't cover error handling, permissions, or what happens if multiple matching sections exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, detailed behavioral explanation, and organized parameter documentation. Every sentence earns its place by providing essential information without redundancy. The use of sections (Args, Returns) enhances readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (section-aware insertion with conditional creation), no annotations, and the presence of an output schema (implied by 'Returns'), the description is largely complete. It explains the core algorithm and parameters well but could benefit from more behavioral context about edge cases. The output schema handles return values adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for all 4 parameters: 'nombre_archivo' as the note name, 'seccion' as the section name with examples, 'contenido' as content to insert, and 'crear_si_no_existe' explaining the conditional creation behavior. This adds substantial value beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('añade contenido debajo de una sección específica') and resource ('de una nota'), distinguishing it from siblings like 'agregar_a_nota' (which likely adds to the entire note) and 'editar_nota' (which may edit arbitrary parts). It precisely describes the insertion behavior relative to heading levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when content needs to be added below a specific section heading in a note, with precise positioning logic. It doesn't explicitly state when not to use it or name alternatives among siblings, but the context strongly implies it's for section-specific additions rather than general note editing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool performs a destructive deletion operation and requires confirmation. However, it lacks details on permissions, error handling, or what happens to linked data, leaving gaps in transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose and key requirement, followed by structured sections for Args and Returns. Every sentence earns its place with no wasted words, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive operation with 2 parameters), no annotations, and an output schema (implied by 'Returns'), the description is mostly complete. It covers purpose, usage, parameters, and return value, but lacks details on behavioral aspects like error cases or side effects, which holds it back from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'nombre_archivo' as the file name to delete and 'confirmar' as a required confirmation (must be True). This covers both parameters effectively, though it doesn't specify format details like file extensions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Elimina') and resource ('una nota del vault'), distinguishing it from sibling tools like 'crear_nota', 'editar_nota', and 'mover_nota' which handle different operations on notes. The title being null doesn't affect this clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by mentioning 'requiere confirmación', indicating when to use this tool (for deletion with confirmation). However, it doesn't explicitly state when not to use it or name alternatives like 'mover_nota' for archiving instead of deletion, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the search method (ripgrep or Python fallback) and the AND logic for multiple terms, which is useful. However, it doesn't mention performance aspects (e.g., speed, rate limits), error handling, or what happens with empty results, leaving 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by key behavioral details (multiple terms with AND logic), and then a structured parameter explanation. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with three parameters), no annotations, and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, usage context, and parameter semantics well, but lacks some behavioral details like error cases or performance limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It clearly explains all three parameters: 'texto' (text to search, can include multiple words), 'carpeta' (specific folder to search, empty means entire vault), and 'solo_titulos' (search only in note titles). This adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching text in vault notes using intelligent search (ripgrep or Python fallback). It specifies the resource (notes in the vault) and the operation (searching with intelligent algorithms), distinguishing it from siblings like 'buscar_notas_por_fecha' (search by date) or 'leer_nota' (read a note).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it supports multiple search terms with AND logic (e.g., 'nas ssh' finds notes containing both words) and allows optional folder filtering. However, it doesn't explicitly state when to use this tool versus alternatives like 'buscar_notas_por_fecha' or 'obtener_notas_por_tag', leaving some ambiguity for the agent.
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?
No annotations are provided, so the description carries the full burden. It discloses critical behavioral traits: the tool is mandatory for AI agents, must be invoked before write operations, and the rules contain restrictions (e.g., no emojis, allowed formats). This adds value beyond basic functionality, though it doesn't detail response format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidelines in a clear warning format. Every sentence adds value: the first states what it does, the second emphasizes mandatory usage, and the third explains why (critical restrictions). It could be slightly more concise by merging sentences, but it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation), no annotations, 0 parameters, and an output schema exists (so return values are documented elsewhere), the description is complete. It covers purpose, mandatory usage context, and behavioral implications (restrictions), which is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on usage context. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtiene' (gets) and the resource 'reglas globales del Agente' (agent's global rules), with the specific file path (.agent/REGLAS_GLOBALES.md) provided. It distinguishes this from siblings by focusing on reading global rules rather than notes, tags, or other operations. However, it doesn't explicitly differentiate from tools like 'leer_nota' or 'obtener_instrucciones_agente' in terms of content type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states this tool is 'OBLIGATORIO' (mandatory) for AI agents and must be used 'ANTES de realizar cualquier escritura o modificación en el vault' (BEFORE any writing or modification in the vault). It clearly defines when to use it (before write operations) and implies when not to use it (for other purposes like reading notes). No alternatives are named, but the context is unambiguous.
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 potentially destructive operation (implied by 'reemplaza'), includes safety features ('solo_preview' for dry-run, 'limite' for safety), and specifies search behavior ('texto literal, no regex'). However, it doesn't mention permissions needed or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and front-loaded: first sentence states core purpose, second provides use cases, then organized Args and Returns sections. Every sentence earns its place with no redundancy. The Spanish text is clear and efficient despite conveying substantial information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 5-parameter mutation tool with no annotations, the description provides excellent completeness: clear purpose, usage context, parameter semantics, behavioral transparency about safety features, and mentions return values. With an output schema present, it doesn't need to detail return format. The description adequately covers what an agent needs to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all 5 parameters in the Args section. Each parameter gets clear semantic explanation beyond type information: 'buscar' specifies 'texto literal, no regex', 'carpeta' explains 'vacío = todo el vault', 'solo_preview' describes its dry-run function, and 'limite' mentions its safety purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Busca y reemplaza texto') and resources ('en todas las notas del vault'), distinguishing it from siblings like 'buscar_en_notas' (search only) or 'editar_nota' (edit single note). It provides concrete use cases ('corregir enlaces rotos, renombrar tags, o actualizar rutas') that clarify its scope beyond basic search/replace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('Útil para corregir enlaces rotos, renombrar tags, o actualizar rutas'), but doesn't explicitly mention when not to use it or name specific alternatives. It implies usage for bulk operations across the vault, but lacks explicit comparison to siblings like 'editar_nota' for single-note edits.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It effectively describes critical behavioral traits: it's a creation/mutation tool (implied by 'crea'), requires specific prerequisites (reading rules), and has integration with skills and templates. However, it doesn't mention potential side effects like overwriting existing notes or error handling, which leaves a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured with a clear purpose statement, critical warnings, usage guidelines, and parameter details. It's front-loaded with essential information. While slightly verbose due to the warning section, every sentence earns its place by providing necessary context and instructions, avoiding redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, but with an output schema), the description is complete enough. It covers purpose, usage guidelines, behavioral context, and parameter semantics thoroughly. The presence of an output schema means return values don't need explanation, and the description addresses all other aspects adequately for a creation tool in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 7 parameters in the 'Args' section, explaining each one's purpose (e.g., 'titulo: Título de la nota', 'carpeta: Carpeta donde crear la nota'). This adds significant value beyond the bare schema, though it doesn't detail format constraints or examples beyond the template example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Crea una nueva nota en el vault' (creates a new note in the vault), which is a specific verb+resource combination. It distinguishes itself from siblings like 'editar_nota' (edit note) and 'eliminar_nota' (delete note) by focusing on creation. The purpose is unambiguous and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives, including a critical warning to avoid generic file system tools like 'write_file' and to always use this tool for creating notes in the vault. It also specifies prerequisites (reading global rules with 'leer_contexto_vault' and 'obtener_reglas_globales') and context (checking for applicable skills). This covers when, when-not, and alternatives comprehensively.
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 behaviors: creates a note in a specific folder (Inbox/00_Bandeja), adds automatic timestamping, and is designed for frictionless quick capture. However, it doesn't mention potential limitations like file size constraints, error conditions, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It begins with a clear purpose statement, provides usage context, then details parameters and return value in separate labeled sections. Every sentence earns its place by adding valuable information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with output schema), the description is mostly complete. It covers purpose, usage, parameters, and return value. The output schema existence means the description doesn't need to detail return values. However, it could benefit from mentioning any constraints or edge cases for a more complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant semantic value beyond the input schema, which has 0% description coverage. It clearly explains that 'texto' is the content to capture and 'etiquetas' are optional comma-separated tags, providing essential context that the schema alone lacks. This fully compensates for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('captura rápida', 'crea una nota') and resources ('en la carpeta Inbox (00_Bandeja)'). It distinguishes itself from siblings like 'crear_nota' by emphasizing frictionless, quick capture to a specific inbox folder with automatic timestamping, rather than general note creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Ideal para "guardar esto rápido" sin pensar en ubicación o formato'), providing clear context for its intended use case. It implicitly distinguishes from alternatives by focusing on quick capture versus more deliberate note creation or editing tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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: it discloses critical behavioral traits like the destructive 'reemplazando todo su contenido' nature, mandatory prerequisites ('ANTES de ejecutar, DEBES leer la nota original'), and constraints like respecting global rules and requiring total content. It doesn't mention error handling or rate limits, but covers key operational aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear purpose statement, critical warnings in a highlighted section, and separate Args/Returns sections. Every sentence earns its place, though the warning section is somewhat verbose; overall it's appropriately sized and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive edit operation with no annotations, the description is complete: it covers purpose, usage guidelines, behavioral traits, parameter details, and mentions output (confirmation/error message). With an output schema present, it doesn't need to detail return values, making this comprehensive for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It explicitly documents both parameters with clear semantics: 'nombre_archivo' as the file name/path with an example, and 'nuevo_contenido' as the complete updated content including YAML frontmatter, adding crucial context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('edita una nota existente') and resource ('nota'), and distinguishes it from siblings like 'agregar_a_nota' or 'crear_nota' by specifying it replaces entire content rather than appending or creating new notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: when to use (editing existing notes with full content replacement), when not to use (no generic file system tools), and alternatives (must first read with 'leer_nota'). It also references sibling tools like 'leer_nota' for prerequisites.
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?
No annotations are provided, so the description carries the full burden. It effectively discloses behavioral traits: it's a read-only operation ('Lee'), returns a summary ('Devuelve un resumen'), and informs about specific aspects (folder structure, templates, agent configuration). However, it doesn't mention potential side effects like caching or performance impacts, which could be relevant for a first-run tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It front-loads the core purpose, uses a clear warning for critical usage guidelines, lists key informational points with bullet-like formatting, and ends with the return value. Every sentence earns its place by adding essential value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read-only, parameter-less initial exploration tool), the description is complete. It explains the purpose, mandatory usage, specific information provided, and return value. With an output schema present, it doesn't need to detail return values, and the absence of annotations is compensated by the clear behavioral disclosure in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage. A baseline of 4 is applied as it efficiently handles the parameter-less case without unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Lee' - reads) and resources ('estructura general del vault y estadísticas clave' - general vault structure and key statistics). It distinguishes itself from siblings by being a mandatory first-step tool for vault exploration, unlike other tools that perform specific operations like creating, editing, or analyzing notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines with a mandatory warning: 'Esta debe ser SIEMPRE la PRIMERA herramienta que ejecutes al comenzar cualquier tarea con el vault.' It clearly states when to use this tool (first for any vault task) and implies when not to use it (after initial exploration). The context of informing about folder structure, templates, and agent configuration further guides its application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains the probabilistic nature of suggestions, the confidence scoring system, the fallback behavior to rules, the basis in existing similar notes, and the non-infallible nature requiring user judgment. This goes well beyond basic functional description to cover important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, agent instructions, parameters, returns) and front-loads the core purpose. While comprehensive, it could be slightly more concise - some phrasing could be tightened without losing clarity. Every sentence earns its place by adding important information, but minor verbosity keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (probabilistic suggestions with confidence scoring), lack of annotations, and 0% schema description coverage, the description provides excellent completeness. It covers purpose, usage guidelines, behavioral traits, parameter semantics, and return values. The presence of an output schema means the description doesn't need to detail return structure, and it appropriately focuses on semantic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation in the schema, and it does so effectively. It explicitly lists and explains all three parameters (titulo, contenido, etiquetas) in the 'Args' section, providing clear semantic meaning for each that isn't available from the schema alone. The description adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Sugiere carpetas candidatas para una nota nueva según su contenido y tags.' This specifies the verb (sugerir/suggest), resource (carpetas/folders), and scope (para una nota nueva/for a new note). It distinguishes from siblings like 'mover_nota' (move note) or 'crear_nota' (create note) by focusing on folder suggestions based on content analysis rather than direct note manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines in the 'IMPORTANTE PARA AGENTES DE IA' section, detailing when to use it (for folder suggestions based on note content/tags), how to evaluate results (consider confidence scores and user context), and when to use alternatives (if confidence is low, ask the user directly). It also clarifies what the tool is NOT (definitive answers) and mentions fallback mechanisms.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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